1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Các kỹ sư của Calif đã tạo ra một exploit hỏng bộ nhớ kernel macOS chạy trên Apple M5 và đã chuyển báo cáo nghiên cứu lỗ hổng cho Apple
  • Chuỗi exploit nhắm vào phần cứng M5 bare-metal với MIE được bật, và toàn bộ chi tiết kỹ thuật sẽ được công bố sau khi Apple phát hành bản vá
  • Mục tiêu là macOS 26.4.1 (25E253), bắt đầu từ người dùng cục bộ không có đặc quyền và chỉ với các lời gọi hệ thống thông thường đã đạt tới root shell
  • Việc triển khai sử dụng hai lỗ hổng cùng nhiều kỹ thuật khác nhau, và Calif xem đây là exploit kernel macOS đầu tiên được công khai trên phần cứng MIE
  • Mythos Preview đã hỗ trợ việc xác định lỗi và phát triển exploit, nhưng để vượt qua các biện pháp giảm thiểu mới như MIE vẫn cần đến chuyên gia con người

Exploit kernel macOS vượt qua MIE trên M5

  • Các kỹ sư của Calif, cùng với Mythos Preview, đã tạo ra một exploit hỏng bộ nhớ kernel macOS chạy trên silicon Apple M5, và trực tiếp chuyển báo cáo nghiên cứu lỗ hổng cho Apple tại Apple Park
  • Chuỗi này nhắm vào phần cứng M5 bare-metal với MIE(Memory Integrity Enforcement) được bật
  • Mục tiêu là macOS 26.4.1 (25E253); đây là một chuỗi leo thang đặc quyền cục bộ ở kernel chỉ thao tác trên dữ liệu, bắt đầu từ người dùng cục bộ không có đặc quyền, chỉ dùng các lời gọi hệ thống thông thường và kết thúc bằng root shell
  • Việc triển khai bao gồm hai lỗ hổng và nhiều kỹ thuật khác nhau; sau khi Apple vá các lỗ hổng và đường tấn công, báo cáo dài 55 trang cùng toàn bộ chi tiết kỹ thuật sẽ được công bố
  • Tiến độ diễn ra rất nhanh
    • Bruce Dang đã phát hiện lỗi vào ngày 25 tháng 4
    • Dion Blazakis gia nhập Calif vào ngày 27 tháng 4
    • Josh Maine đã tạo công cụ, và đến ngày 1 tháng 5 thì exploit hoạt động hoàn chỉnh

Ý nghĩa của MIE và Mythos Preview

  • Hỏng bộ nhớ vẫn là loại lỗ hổng phổ biến nhất, bao gồm cả trên iOS và macOS; nếu không thể ngăn chặn hoàn toàn thì cần các biện pháp giảm thiểu để nâng chi phí tấn công
  • Apple đã đưa nhiều cơ chế phòng vệ vào phần cứng với sự cân bằng giữa hiệu năng và bảo mật, đồng thời tăng độ khó vượt qua bằng cách kiểm soát toàn bộ ngăn xếp
  • MIE là một hệ thống an toàn bộ nhớ có hỗ trợ phần cứng dựa trên MTE (Memory Tagging Extension) của ARM, và được giới thiệu như một tính năng bảo mật quan trọng trên Apple M5 và A19
  • Theo nghiên cứu của Apple, MIE cản trở mọi chuỗi exploit công khai nhằm vào iOS hiện đại, bao gồm cả các bộ công cụ exploit Coruna và Darksword bị rò rỉ gần đây
  • Calif đã khám phá cách AI có thể đóng góp vào việc xây dựng exploit vẫn hoạt động trong môi trường MTE, và khi MIE vốn tập trung vào iOS của Apple cũng được áp dụng cho M5 trên các MacBook mới nhất, các đường tấn công vào macOS trở nên khả thi
  • Mythos Preview đã hỗ trợ xuyên suốt quá trình xác định lỗi và phát triển exploit, và với những dạng vấn đề đã được học trước đó, nó có thể khái quát hóa gần như sang các vấn đề cùng loại
  • Lý do Mythos tìm ra lỗi nhanh là vì các lỗi đó thuộc những kiểu đã được biết đến; còn việc tự động vượt qua các biện pháp giảm thiểu tối tân mới như MIE vẫn thuộc phạm vi của các chuyên gia con người
  • Calif đã thử nghiệm giới hạn của sự kết hợp giữa mô hình hàng đầu và chuyên gia, và tổ hợp này có thể hoàn thành một exploit hỏng bộ nhớ kernel trong vòng một tuần để đối phó với các cơ chế bảo vệ hàng đầu
  • MIE không phải là cơ chế dùng để chặn hoàn toàn hacker, và nếu có lỗ hổng phù hợp thì vẫn có thể bị né tránh
  • Trong loạt bài MAD Bugs, Calif cho rằng các hệ thống AI đang phát hiện ngày càng nhiều lỗ hổng, và một số trong đó có thể đủ mạnh để vượt qua các biện pháp giảm thiểu nâng cao như MIE
  • Vào thời điểm Apple tạo ra MIE, chưa có môi trường như Mythos Preview; công việc lần này là một kết quả ban đầu cho thấy áp lực mà việc tìm lỗi dựa trên AI đang gây ra lên các kỹ thuật giảm thiểu nâng cao

1 bình luận

 
Ý kiến trên Hacker News
  • Chỉ nhìn phần trình diễn thì trên nền tảng bug bounty của Apple, đây có vẻ là lỗ hổng trị giá 100.000 USD, nhưng nếu biết cách đóng gói thì cũng có thể thành lỗ hổng trị giá 1,5 triệu USD
    Chỉ cần tái hiện trên bản beta của macOS, quy thành truy cập trái phép, và nếu có thể thì trình diễn cả trong chế độ Lockdown

    • Cái này có vẻ là leo thang đặc quyền cục bộ (LPE), còn điều nói ở trên thì gần với thực thi mã từ xa không cần nhấp chuột (RCE) hơn
  • Có vẻ thế giới hoàn toàn chưa sẵn sàng cho tác động của LLM đối với các vấn đề bảo mật
    Nếu là thật thì đáng chúc mừng đội Calif, còn chi tiết thì quá kỹ thuật nên khó mà hiểu hết, nhưng đang chờ bản báo cáo dài 55 trang

    • Tôi cũng đồng ý, nhưng điều đáng lo là con người
      Nghe nói ở khắp nơi có các lập trình viên đẩy các thay đổi mã do LLM tạo ra vào production mà bản thân họ cũng không thực sự hiểu mình đang triển khai cái gì
      Càng nhiều thay đổi chồng chất thì mức độ hiểu về codebase càng giảm, còn hành vi thì càng rủi ro hơn
      Tệ hơn nữa là kiểu hành xử này đang được thúc đẩy trực tiếp hoặc gián tiếp từ phía lãnh đạo. Chẳng hạn như mục tiêu tốc độ phi thực tế, thăng chức bằng các sáng kiến mơ hồ kiểu "dùng AI", dồn quá tải lên các lập trình viên còn lại sau sa thải, hay đặt các lập trình viên non kinh nghiệm vào vai trò senior
      Có cảm giác thế giới đang phát điên khi một phần lớn ngành công nghiệp phải chật vật học lại những điều cơ bản của bảo mật
    • Cứ như thể đang giả định rằng blue team và các kỹ sư chỉ ngồi không làm gì
  • LLM sẽ tạo ra cực kỳ nhiều lỗ hổng kiểu Rube Goldberg trong vài năm tới
    Chuyện đó đã bắt đầu rồi, và dù trường hợp này không phải vậy thì nó thực sự đang xảy ra

    • Về mặt lý thuyết, có lẽ việc xây dựng một hệ thống an toàn tuyệt đối vốn đã là điều bất khả thi về mặt vật lý
      Cũng giống như không tồn tại tế bào nào miễn nhiễm với mọi loại virus
      Có lẽ từ trước tới nay chúng ta chỉ sống sót nhờ một dạng bảo mật nhờ sự mơ hồ, mà cái sự mơ hồ đó rốt cuộc chỉ có nghĩa là chẳng ai có đủ thời gian và tập trung để thực sự phân tích mã
    • Không rõ ý là dùng vibe coding để cấy những lỗ hổng như vậy vào kernel, hay là để tìm ra chúng
  • Đáng tiếc là còn hơi thiếu chi tiết
    Tôi rất tò mò lỗi này đã vượt qua MTE bằng cách nào

    • Memory Tagging Extension
      Arm đã công bố đặc tả Memory Tagging Extension (MTE) vào năm 2019 như một công cụ giúp phần cứng phát hiện lỗi hỏng bộ nhớ
      MTE là hệ thống gắn thẻ bộ nhớ và kiểm tra thẻ, gắn một giá trị bí mật làm thẻ cho mọi lần cấp phát bộ nhớ
      Sau đó phần cứng chỉ cho phép truy cập khi yêu cầu truy cập bộ nhớ chứa đúng giá trị bí mật tương ứng
      Nếu giá trị bí mật không khớp thì ứng dụng sẽ crash, sự kiện được ghi lại, và lập trình viên có thể xác định lỗi hỏng bộ nhớ ngay khi nó xảy ra
      https://support.apple.com/guide/security/operating-system-in...
    • Đọc thêm về tấn công chỉ dữ liệu thì tôi hiểu ra
      (https://www.usenix.org/publications/loginonline/data-only-at...)
      Chương trình không thực sự bị thay đổi, mà chỉ bị ép thực hiện hành vi vốn không buộc MTE phải can thiệp, nên MTE không bị kích hoạt
      Điều tôi còn thắc mắc là tại sao Apple lại không dùng kiểm tra fbounds ở đây
      Vì ở những nơi khác họ đã áp dụng nó khá quyết liệt
      Nếu kết hợp MTE với kiểm tra fbounds toàn diện thì hệ điều hành có thể trở nên cực kỳ vững chắc
    • Bộ nhớ GPU, shader v.v. không được MTE hay PAC bảo vệ
      Họ nói là "data-only", nên có thể lệnh GPU phù hợp với trường hợp này
    • Tôi cũng có cùng câu hỏi, và nếu đây là tấn công chỉ dữ liệu thì có lẽ bài học là MIE có giảm được nhiều đường tấn công, nhưng không loại bỏ hết mọi primitive hỏng hóc hữu dụng
    • Đây không phải lần đầu lỗi vượt qua được MTE
      Năm ngoái trên Google Pixel cũng có chuyện tương tự
      https://github.blog/security/vulnerability-research/bypassin...
  • Điều đáng ngạc nhiên là Apple vẫn chưa thực sự dùng Swift, ngôn ngữ được cho là an toàn, một cách nghiêm túc ở nội bộ
    Khiến người ta tự hỏi liệu toàn bộ Swift 6 có gần như chỉ là marketing hay không

    • Họ chắc chắn có dùng
      Một trong những lý do Embedded Swift ra đời là để thay thế firmware iBoot hiện được viết bằng một phương ngữ C có ý tưởng tương tự Fil-C bằng thứ gì đó tốt hơn
      Nhưng chuyện này cũng chẳng khác gì kernel Linux
      Việc cho phép Rust không có nghĩa là cả thế giới được viết lại từ đầu, và người tỉnh táo sẽ không cố dùng Claude để viết lại kernel
    • Apple rõ ràng có dùng Swift
      Gần đây nó đã được thêm vào trình phân tích cú pháp CSS của Safari, và một phần Secure Enclave cũng chạy ở dạng nhúng
      Tôi biết từ thời Strangeloop đã có thảo luận về việc đưa nó vào kernel, nhưng không rõ đã tiến xa đến đâu
      Tách chuyện đó ra thì Apple cũng đã thúc đẩy rất mạnh kiểm tra fbounds của clang, và điều này có thể đạt được một phần nhỏ nhưng quan trọng trong những gì ngôn ngữ an toàn bộ nhớ mang lại
      Tôi cũng muốn thấy việc áp dụng Swift hay các ngôn ngữ thay thế tăng lên hơn nữa, và luôn hoan nghênh việc có thêm cạnh tranh trong mảng ngôn ngữ an toàn
    • Có thể bạn sẽ quan tâm tới tùy chọn Strict Memory Safety
      https://docs.swift.org/compiler/documentation/diagnostics/st...
  • Tôi đã cố tình mua M5 vì MIE, giờ lại thấy mình hơi ngốc

    • Không cần phải vậy
      MTE chặn được một mảng lớn lỗ hổng, và giờ các kỹ thuật như ROP và JOP trở nên rất khó hoặc gần như bất khả thi
    • Nên lo về malware npm/PyPI hơn là lỗi hỏng bộ nhớ
  • Bài viết đã được chỉnh sửa à? Phần giải thích về việc ghé thăm tại chỗ hầu như không có

  • Trông như lại là một đợt marketing thổi phồng nữa cho Mythos
    Báo cáo về curl điềm tĩnh hơn nhiều
    https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-v...

    • Những người này không làm ở Apple hay Anthropic