- tachy0n là một trường hợp công khai exploit jailbreak 0day mới nhất dành cho iOS 13.0~13.5
- Lỗi này là một race condition trong syscall
lio_listio được gọi là Lightspeed, khai thác lỗ hổng LPE (leo thang đặc quyền) của kernel
- Lỗ hổng này đã từng được khai thác thực tế trong nhiều dự án jailbreak như Spice và unc0ver, đồng thời bài viết giải thích phương thức khai thác và các kỹ thuật hack liên quan đến vấn đề quản lý bộ nhớ
- Sau khi exploit này được công khai, Apple đã vá lỗi và đưa vào kiểm thử hồi quy, đồng thời tăng cường mạnh mẽ cơ chế tách biệt object kernel (Zone, kheap, v.v.) và bảo vệ con trỏ
- Từ iOS 14 trở đi, môi trường jailbreak và kernel exploit đã thay đổi về căn bản, dẫn đến tình trạng không còn kernel exploit công khai nào tồn tại nữa
0. Mở đầu
- tachy0n là một exploit cũ áp dụng cho iOS 13.0 đến 13.5
- Được công khai dưới dạng 0day trong unc0ver v5.0.0 vào ngày 23 tháng 5 năm 2020, và chỉ sau đúng 1 tuần Apple đã vá khẩn cấp
- Lỗ hổng này trước đó đã từng được sử dụng như một 1day, nên được đánh giá là một trường hợp có ý nghĩa về mặt kỹ thuật exploit
- Đây là bài viết giải thích chi tiết nguồn gốc lỗ hổng và quá trình phát hiện
1. Lightspeed
- Lỗ hổng này là bug Lightspeed (CVE-2020-9859, v.v.) do Synacktiv công bố, trong đó xảy ra vấn đề race condition khi giải phóng bộ nhớ ngữ cảnh I/O bất đồng bộ của syscall
lio_listio
- Bằng cách điều chỉnh thời điểm của các thao tác I/O để tạo điều kiện double free bộ nhớ, có thể chồng nhiều object lên cùng một vùng nhớ thông qua việc giải phóng object hai lần
- Cấu trúc cấp phát bộ nhớ động trong zone
kalloc.16 của kernel được tận dụng trong exploit
- Về bản chất, đây là cách lặp lại race condition nhiều lần để tăng xác suất thành công
2. Spice
- Exploit này từng được sử dụng trong jailbreak Spice do team Jake Blair phát triển trước đây
- racoon và app đã triển khai các biến thể exploit khác nhau, với mục tiêu chính là giả mạo mach port
- Vào thời iOS 11.x, việc vượt qua PAN (Protection Against Null dereference) còn tương đối dễ, và nhiều kỹ thuật hack kết hợp với kernel infoleak cùng sandbox escape đã được thử nghiệm
- Trong trường hợp racoon, do bị hạn chế truy cập IOKit,
OSUnserializeXML được dùng để tạo object mục tiêu dùng cho spray trong zone tương ứng của kernel
- Bài viết cũng mô tả các khác biệt chi tiết và sự phát triển kỹ thuật tiếp theo liên quan đến sysctl_procargsx, rò rỉ bộ nhớ kernel chưa khởi tạo, chính sách sandbox, v.v.
3. unc0ver
- Khi được áp dụng trong unc0ver, cấu trúc exploit được thiết kế để hoạt động trên phạm vi rộng các SoC, từ A8 đến A13
- Bằng cách theo dõi việc lồng và chồng lấp của các object OSData, exploit kiểm soát vùng nhớ bằng cách giải phóng/cấp phát object mong muốn vào đúng thời điểm
- Các object kernel như IOMemoryDescriptor được tận dụng để làm lộ địa chỉ bộ đệm dữ liệu do người dùng kiểm soát, đồng thời triển khai đọc/ghi trực tiếp từ kernel
- Exploit cũng khai thác phù hợp các điểm yếu trong chính sách bộ cấp phát bộ nhớ kernel của iOS 13, chẳng hạn như vượt qua zone_require
- Có thể xem chi tiết toàn bộ cách triển khai exploit trong kho GitHub công khai (tachy0n)
4. Ảnh hưởng tiếp theo
- Việc công khai một 0day exploit đã gây tiếng vang lớn trong cộng đồng bảo mật cũng như với Apple
- Chỉ 4 giờ sau khi exploit thực tế được công khai, Project Zero và Synacktiv đã tiến hành phân tích chi tiết và đối phó
- Sau khi vá lỗi, Apple đã thêm kiểm thử hồi quy chính thức cho lỗ hổng này vào XNU, cho thấy sự chuyển hướng sang chiến lược tăng cường bảo mật mang tính căn cơ
- Từ iOS 14, những thay đổi quy mô lớn như tách biệt vùng cấp phát, secure guard cho object, PAC (Pointer Authentication Code), cấu trúc kheap, v.v. đã được đưa vào, làm tăng mạnh độ khó khi phát triển exploit
- Giờ đây bản thân chiến lược exploit trở nên quan trọng hơn, và khoảng cách giữa thông tin công khai với nghiên cứu không công khai ngày càng lớn, đến mức với iOS 17~18 thì thực tế không còn kernel exploit công khai nào nữa
5. Kết luận
- Đây là một trường hợp cho thấy rất rõ việc lĩnh vực bảo mật/jailbreak iOS đã thay đổi đầy kịch tính chỉ trong 5 năm
- Nó mang lại góc nhìn sâu sắc về cách cộng đồng jailbreak/exploit, các nhà nghiên cứu và cả Apple đã thay đổi định hướng kỹ thuật ra sao
- Thời kỳ chia sẻ IL và cùng nhau thử thách nay đã là chuyện quá khứ, và từ sau iOS 14, việc chia sẻ thông tin exploit đã giảm đi rõ rệt
Tham khảo và liên hệ
2 bình luận
Phần cứng của Apple đúng là rất xuất sắc, nhưng phần mềm thì đầy rẫy ý đồ muốn trói buộc người dùng.
Ngay cả khi chỉ muốn chạy một ứng dụng do chính mình tạo và build trên đúng thiết bị của mình, bạn cũng cần một gói đăng ký 100 đô la.
Nếu là lập trình viên dùng các ứng dụng mã nguồn mở quy mô nhỏ đến vừa và tự build để dùng,
thì trên thiết bị Apple, thay vì phải lợi dụng lỗ hổng để jailbreak rồi sideload, cứ dùng Android còn thoải mái hơn.
Ý kiến trên Hacker News
SockPuppet trước đây cũng từng được dùng cho một bản jailbreak thời iOS 12, và Ned Williamson của Project Zero đã báo cho Apple, sau đó lỗ hổng được vá trong iOS 12.3 nhưng rồi lại tái xuất ở iOS 12.4
Có lẽ Apple đã fork XNU sang một nhánh riêng nên bỏ sót bản vá đó, và vấn đề lớn hơn về bản chất là hoàn toàn không có kiểm thử hồi quy cho các lỗ hổng mới/cũ như thế này
Tôi đã tự động hóa kiểm thử hồi quy chỉ với vài lỗ hổng 1-day đã biết và chạy thử, kết quả là phát hiện lại lỗ hổng ngay lập tức
Tôi cũng tò mò không biết trong các dự án mã nguồn mở như Linux, FreeBSD, OpenWRT, OpenSSH... có chạy kiểm thử hồi quy cho các lỗ hổng cũ trên phiên bản mới hay không
Nếu có thể viết từng lỗ hổng dưới dạng tự động hóa và đủ điều kiện đầu tư tài nguyên để chạy trong CI, tôi nghĩ lợi ích mang lại sẽ rất lớn
Tôi chia sẻ trải nghiệm từ thời đại học cách đây 20 năm khi làm QA tình nguyện cho Mozilla, nơi đã có hàng trăm trường hợp kiểm thử hồi quy
Chủ yếu là lỗi rendering/layout và lỗi JS engine, và nếu tạo được test case tối giản thì có cấu trúc để thêm ngay vào pipeline CI
Lỗi thì không thể tránh hoàn toàn, nhưng điều tệ nhất là một lỗi đã sửa lại xuất hiện lần nữa vì đó là lãng phí thời gian và chi phí, và tôi cho rằng những tổ chức quan tâm đến chất lượng nhất định phải đầu tư nhiều vào kiểm thử hồi quy
Đáng tiếc là cũng có nhiều tổ chức xem nhẹ QA hoặc chỉ giao cho bên ngoài, chứ không thực sự chú ý đúng mức
Tôi không thể hiểu nổi việc Apple lại không có kiểm thử hồi quy liên quan đến jailbreak
Từ trước, ở Mozilla và những nơi tương tự đã xây dựng môi trường QA và CI/CD rất tốt bằng các công cụ như Tinderbox, Bugzilla; tôi từng nghĩ cách làm này đã là chuyện phổ biến từ trước cả khi khái niệm DevOps xuất hiện, nhưng về sau mới biết thực tế không hẳn vậy
Có đến hàng nghìn test case, hình như là Sqlite
Ngoài ra, nếu không backport bản vá thì khả năng cao cũng sẽ không backport luôn cả các bài test đó
Rốt cuộc định luật Conway (Conway's law) vẫn áp dụng nguyên vẹn giữa bảo mật và phát triển tính năng
Vì thế, ngay cả ở những tổ chức có kiểm thử hồi quy tốt trong quy trình build/release, các vấn đề liên quan đến bảo mật vẫn có khả năng bị rơi rụng do cấu trúc tổ chức nội bộ
ý kiến cho rằng các cơ quan tình báo (G10, Nga, Trung Quốc, Bắc Triều Tiên...) và nhiều nhóm tư nhân chắc chắn đều đang làm kiểm thử hồi quy lỗ hổng theo cách này
Người này ví nó như đang nói chuyện với bạn bằng ngoại ngữ, rồi ngay khoảnh khắc sau chủ đề chuyển sang một lĩnh vực chuyên sâu như phẫu thuật não hay vật lý hạt nhân, khiến đầu óc hoàn toàn trắng xóa
Điều đó gợi nhớ đến lần trước đây tôi từng phải phiên dịch một cuộc trò chuyện về sửa chữa nhà máy thép
Tôi thấy tiếc vì thời của jailbreak đã qua; dù tôi cũng không tận dụng chiếc iPad đã jailbreak vào việc gì đặc biệt hữu ích, bản thân việc đó đã đủ vui rồi
Nếu là bây giờ, tôi muốn cài ứng dụng tethering, UTM hoặc giải pháp JIT
SideStore có vẻ đầy hứa hẹn nên tôi muốn thử, nhưng tài khoản Apple của tôi trước đây là tài khoản developer trả phí và 10 app ID vẫn chưa hết hạn, nên bị hạn chế khi cài các ứng dụng như vậy
Muốn làm thì phải tạo tài khoản mới hoặc trả tiền lại
Nếu không có jailbreak thì hoàn toàn không có lý do gì để tôi dùng iPhone làm điện thoại chính, và cuối cùng tôi chuyển sang Android
Khi đó Android cũng đã bắt kịp khá nhiều về mặt tính năng cơ bản
Có cần qua broker trung gian không, hay có email/cửa tiếp nhận chính thức nào, và liệu có nguy cơ chỉ bị chôn vùi ở tuyến hỗ trợ cấp 1 hay không
Như bài viết đã nhắc đến, các cộng đồng private vẫn đang nắm giữ lỗ hổng và Apple vẫn tiếp tục vá chúng
Chỉ là số lượng jailbreak được công khai ra đại chúng đã giảm đi mà thôi