▲

Apple M5에서 첫 공개 macOS 커널 메모리 손상 익스플로잇

 (blog.calif.io)
1P by GN⁺ 10시간전 | ★ favorite | 댓글 1개
  • Calif 엔지니어들이 Apple M5에서 동작하는 macOS 커널 메모리 손상 익스플로잇을 만들고 Apple에 취약점 연구 보고서를 전달함
  • 익스플로잇 체인은 MIE가 활성화된 bare-metal M5 하드웨어를 대상으로 하며, Apple 수정 뒤 전체 기술 세부사항이 공개될 예정임
  • 대상은 macOS 26.4.1 (25E253) 이고, 권한 없는 로컬 사용자에서 일반 시스템 호출만으로 root shell에 도달함
  • 구현에는 두 개의 취약점과 여러 기법이 쓰였으며, Calif는 이를 MIE 하드웨어에서 공개된 첫 macOS 커널 익스플로잇으로 파악함
  • Mythos Preview가 버그 식별과 익스플로잇 개발을 도왔지만, MIE 같은 새 완화책 우회에는 여전히 인간 전문가가 필요함

M5의 MIE를 통과한 macOS 커널 익스플로잇

  • Calif 엔지니어들이 Mythos Preview와 함께 Apple M5 실리콘에서 동작하는 macOS 커널 메모리 손상 익스플로잇을 만들었고, Apple Park에서 Apple에 취약점 연구 보고서를 직접 전달함
  • 이 체인은 MIE(Memory Integrity Enforcement)가 활성화된 bare-metal M5 하드웨어를 대상으로 함
  • 대상은 macOS 26.4.1 (25E253) 이며, 권한 없는 로컬 사용자에서 시작해 일반 시스템 호출만 사용하고 root shell로 끝나는 데이터 전용 커널 로컬 권한 상승 체인임
  • 구현에는 두 개의 취약점과 여러 기법이 포함됐으며, Apple이 취약점과 공격 경로를 수정한 뒤 55페이지 보고서와 전체 기술 세부사항이 공개될 예정임
  • 일정은 빠르게 진행됨
    • Bruce Dang이 4월 25일 버그를 발견함
    • Dion Blazakis가 4월 27일 Calif에 합류함
    • Josh Maine이 도구를 만들었고, 5월 1일 동작하는 익스플로잇이 완성됨

MIE와 Mythos Preview의 의미

  • 메모리 손상은 iOS와 macOS를 포함해 여전히 가장 흔한 취약점 유형이며, 완전히 막기 어렵다면 공격 비용을 높이는 완화책이 필요함
  • Apple은 성능과 보안을 함께 고려해 많은 방어 기능을 하드웨어에 넣었고, 전체 스택을 통제하는 방식으로 우회 난도를 높였음
  • MIE는 ARM의 MTE(Memory Tagging Extension)를 기반으로 한 하드웨어 지원 메모리 안전 시스템이며, Apple M5와 A19의 주요 보안 기능으로 도입됨
  • Apple의 연구에 따르면 MIE는 최근 유출된 Coruna와 Darksword 익스플로잇 키트를 포함해 현대 iOS에 대한 모든 공개 익스플로잇 체인을 방해함
  • Calif는 MTE 환경에서도 동작하는 익스플로잇 구축에 AI가 어떻게 기여할 수 있는지 탐색해 왔고, iOS 중심인 Apple의 MIE가 최신 MacBook의 M5에도 적용되면서 macOS 공격 경로가 가능해짐
  • Mythos Preview는 버그 식별과 익스플로잇 개발 전반을 도왔고, 이미 학습한 문제 유형에는 거의 같은 유형의 문제까지 일반화할 수 있음
  • Mythos가 버그를 빠르게 찾은 이유는 해당 버그들이 알려진 유형에 속했기 때문이며, MIE처럼 새로운 최고 수준의 완화책을 자율적으로 우회하는 일은 여전히 인간 전문가의 영역임
  • Calif는 최고 수준의 모델과 전문가가 결합될 때 가능한 범위를 테스트했고, 이 조합은 최상위 보호 장치를 상대로 1주일 안에 커널 메모리 손상 익스플로잇을 완성할 수 있었음
  • MIE는 해커를 완전히 막기 위한 장치가 아니며, 적절한 취약점이 있으면 회피될 수 있음
  • MAD Bugs 시리즈에서는 AI 시스템이 점점 더 많은 취약점을 발견하고 있으며, 그중 일부는 MIE 같은 고급 완화책을 통과할 만큼 강력해질 수 있다고 봄
  • Apple이 MIE를 만든 시점에는 Mythos Preview 같은 환경이 없었고, 이번 작업은 AI 기반 버그 발견이 고급 완화 기술에 가하는 압력을 보여주는 초기 결과물임

함께 보면 좋은 글 β

▲
GN⁺ 10시간전  [-]
Hacker News 의견들

  • 시연 내용만 보면 Apple 버그 바운티 플랫폼에서는 10만 달러짜리 취약점으로 보이지만, 포장을 잘하면 150만 달러짜리 취약점이 될 수도 있음
    MacOS 베타 버전에서 재현하고, 무단 접근으로 규정하며, 가능하면 잠금 모드에서도 보여주면 됨

    • 이건 로컬 권한 상승(LPE) 으로 보이고, 위에서 말한 건 무클릭 원격 코드 실행(RCE)에 가까움

  • 보안 이슈에 대한 LLM의 영향을 세상이 전혀 준비하지 못한 듯함
    사실이라면 Calif 팀에게 축하할 일이고, 세부 사항은 너무 기술적이라 다 이해하긴 어렵겠지만 55쪽짜리 보고서를 기대 중임

    • 나도 동의하지만, 걱정되는 건 사람들임
      여기저기서 개발자들이 자신이 무엇을 배포하는지도 제대로 이해하지 못한 채 LLM 생성 코드 변경을 프로덕션에 밀어 넣는다는 얘기를 듣고 있음
      변경이 누적될수록 코드베이스 이해도는 떨어지고, 행동은 더 위험해짐
      더 나쁜 건 이런 행동이 리더십에 의해 직접적으로든 간접적으로든 밀리고 있다는 점임. 비현실적인 속도 목표, 두루뭉술한 "AI 사용" 이니셔티브로 승진시키기, 해고로 남은 개발자에게 과부하를 주기, 미숙한 개발자를 시니어 역할에 앉히기 같은 식임
      업계의 큰 부분이 보안의 기본을 고생해서 다시 배우려는 듯 세상이 미쳐 돌아가고 있음
    • 블루팀과 엔지니어들이 아무것도 안 하고 손가락만 빨고 있다고 가정하는 듯함

  • LLM은 앞으로 몇 년 동안 루브 골드버그식 취약점을 엄청 만들어낼 것임
    이미 시작됐고, 이번 사례가 그런 건 아니지만 실제로 벌어지고 있음

    • 이론적으로 안전한 시스템을 만드는 것 자체가 물리적으로 불가능할지도 모름
      어떤 바이러스에도 취약하지 않은 세포가 없다고 보는 것처럼 말임
      어쩌면 지금까지는 일종의 모호성에 의한 보안으로 버텨온 것이고, 그 모호성이란 결국 아무도 코드를 실제로 분석할 시간과 집중력을 갖지 못했다는 뜻일 수 있음
    • 그런 취약점을 커널에 바이브 코딩으로 심는다는 뜻인지, 아니면 찾아낸다는 뜻인지 궁금함

  • 아쉽게도 세부 정보가 좀 부족함
    버그가 어떻게 MTE를 통과했는지 매우 궁금함

    • Memory Tagging Extension
      Arm은 2019년에 하드웨어가 메모리 손상 버그를 찾도록 돕는 도구로 Memory Tagging Extension(MTE) 명세를 공개했음
      MTE는 메모리 태깅과 태그 검사 시스템으로, 모든 메모리 할당에 비밀값을 태그로 붙임
      하드웨어는 이후 메모리 접근 요청이 올바른 비밀값을 포함할 때만 접근을 허용함
      비밀값이 맞지 않으면 앱이 크래시되고 이벤트가 기록되며, 개발자는 메모리 손상 버그가 발생하는 즉시 식별할 수 있음
      https://support.apple.com/guide/security/operating-system-in...
    • 데이터 전용 공격을 더 읽어보니 이해가 됨
      (https://www.usenix.org/publications/loginonline/data-only-at...)
      프로그램이 실제로 바뀌는 게 아니라 MTE가 개입해야 할 동작을 강제로 만들지 않으니 MTE가 트리거되지 않음
      다른 궁금증은 Apple이 왜 여기서 fbounds 검사를 쓰지 않았는지임
      다른 곳에서는 꽤 공격적으로 적용해왔기 때문임
      MTE와 전면적인 fbounds 검사를 함께 쓰면 운영체제가 극도로 단단해질 수 있음
    • GPU 메모리, 셰이더 등은 MTE나 PAC로 보호되지 않음
      "data-only"라고 했으니 GPU 명령이 여기에 들어맞을 수도 있음
    • 나도 같은 질문이 들었고, 이게 데이터 전용 공격이라면 MIE가 많은 공격 경로를 줄이긴 하지만 유용한 손상 원시 동작을 전부 없애지는 못한다는 교훈일 수 있음
    • 버그가 MTE를 통과한 게 처음은 아님
      작년에 Google Pixel에서도 비슷한 일이 있었음
      https://github.blog/security/vulnerability-research/bypassin...

  • Apple이 allegedly 안전한 언어인 Swift를 아직도 내부에서 제대로 쓰지 않는다는 게 놀라움
    Swift 6 전체가 거의 마케팅이었나 싶음

    • 확실히 쓰고 있음
      Embedded Swift가 나온 이유 중 하나도 현재 Fil-C와 비슷한 발상의 C 방언으로 작성된 iBoot 펌웨어를 더 나은 것으로 대체하려는 것임
      다만 Linux 커널과 다를 바 없음
      Rust가 허용됐다고 해서 세상이 전부 다시 작성된 건 아니고, 제정신인 사람이라면 Claude로 커널을 재작성하려 들지 않을 것임
    • Apple에서 Swift는 분명 쓰이고 있음
      최근에는 Safari의 CSS 파서로 추가됐고, Secure Enclave 일부에도 임베디드 형태로 동작함
      Strangeloop 시절부터 커널에 넣자는 논의가 있었던 것으로 알지만, 얼마나 진행됐는지는 잘 모르겠음
      그와 별개로 Apple은 clang의 fbounds 검사를 강하게 밀어왔고, 이는 메모리 안전 언어가 제공하는 것의 작지만 중요한 일부를 달성할 수 있음
      Swift나 대안 언어 채택이 더 늘어나는 것도 보고 싶고, 안전한 언어 영역에 더 많은 경쟁이 생기는 건 언제나 환영할 만함
    • Strict Memory Safety 옵션에 관심이 있을 수 있음
      https://docs.swift.org/compiler/documentation/diagnostics/st...

  • MIE 때문에 일부러 M5를 샀는데, 이제 좀 바보가 된 느낌임

    • 그럴 필요 없음
      MTE는 취약점의 큰 덩어리를 막아주고, ROP와 JOP 같은 기법을 이제 매우 어렵게 만들거나 사실상 불가능하게 만듦
    • 메모리 손상 버그보다 npm/PyPI 악성코드를 더 걱정해야 함

  • 글이 수정됐나? 현장 방문에 대한 설명이 별로 없음

  • Mythos를 위한 또 하나의 과장된 마케팅처럼 보임
    curl 보고서는 훨씬 더 차분했음
    https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-v...

    • 이 사람들은 Apple이나 Anthropic에서 일하지 않음
답변달기