▲

Apple의 메모리 무결성 강제(Memory Integrity Enforcement)

 (security.apple.com)
4P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • Apple은 Memory Integrity Enforcement(MIE) 를 도입해, 자체 실리콘 하드웨어와 고급 운영체제 보안을 결합한 혁신적 메모리 안전 체계를 완성함
  • MIE는 항상 활성화된 상태에서 핵심 공격 표면을 보호하며, 성능 저하 없이 모든 iPhone 17과 iPhone Air 기기에 적용됨
  • Enhanced Memory Tagging Extension(EMTE)와 보안 메모리 할당자, 그리고 태그 기밀성 정책을 조합해, 악성 공격에 대한 내성을 현저히 높임
  • 동기화 태그 확인 및 운영체제-하드웨어의 정교한 통합으로 인해, 버퍼 오버플로우 및 사용 후 해제 취약점 차단이 극대화됨
  • 수년간의 공격적 연구와 내부 평가를 통해 공격자 자유도를 제약하고, 현재 기준 가장 강력한 메모리 안전성을 달성함

소개

  • Apple의 Memory Integrity Enforcement(MIE) 는 Apple Silicon 하드웨어와 고도화된 운영체제 보안을 통합하여 항상 활성화되는 메모리 안전 보호 기술
  • 추가적인 성능 저하 없이 다양한 Apple 기기에서 업계 최초의 광범위한 메모리 안전 체계 제공 목표로 개발됨
  • 이는 Apple이 소비자 운영체제 메모리 안전성 역사상 가장 중요한 진보라고 평가하는 기능

보안 위협 배경 및 메모리 안전의 진화

  • iPhone이 대규모 악성코드 공격의 성공 사례가 없는 이유는, mercenary spyware(용병형 스파이웨어) 중심의 복잡한 공격 체인만이 실제 위협으로 관찰되기 때문임
  • 이러한 고도화된 공격(수백만 달러가 드는 소수 표적용)은 메모리 안전 취약점을 공통적으로 악용함
  • Apple은 Swift 같은 안전한 언어 개발과, 보안 메모리 할당자 도입, 시스템 전체의 대규모 완화책을 통해 지속적으로 메모리 안전성을 개선해옴
  • Pointer Authentication Code(PAC) 를 세계 최초로 A12 Bionic에서 도입해 하드웨어-소프트웨어 결합 보안이 대세임을 확립함

하드웨어 기반 메모리 태깅 기술(MTE/EMTE)과 한계 극복

  • Arm이 제시한 Memory Tagging Extension(MTE)은 메모리 할당마다 비밀 태그를 부여해, 올바른 태그로만 접근 허용하는 방식임
  • Apple은 MTE 원본 설계의 단점(비동기 동작 등)을 발견하고, Arm과 협력해 Enhanced Memory Tagging Extension(EMTE) 로 개선함
  • 항상 동기화된 방식으로 태그 확인이 작동되도록 설계, 연속적인 보호 제공이 핵심임

MIE의 계층적 구조와 주요 보호 메커니즘

  • MIE는 kalloc_type, xzone malloc, WebKit의 libpas 등 타입 인지형 보안 할당자와, EMTE, Tag Confidentiality Enforcement(태그 기밀성 보호) 정책의 세 구성으로 이루어짐
  • 할당자는 서로 다른 타입 간 메모리 페이지 단위 보호를 제공하고, EMTE는 동일 타입 버킷 내 작은 메모리 할당의 취약점까지 대응
  • 버퍼 오버플로우, 사용 후 해제(Use-After-Free) 등 일반적 메모리 손상 공격에 대해, 태깅 및 재태깅을 활용해 하드웨어-운영체제가 즉시 탐지·차단함

태그 기밀성 및 부채널(사이드채널) 공격 대응 전략

  • 공격자가 할당자 저장소와 태그 노출을 노리는 것을 막기 위해, Secure Page Table Monitor 등 강한 보호장치 도입
  • 예측실행(speculative execution)을 악용한 부채널 공격에 대비해, Apple Silicon이 태그 정보로 인한 예측실행 영향 자체를 원천 차단하도록 설계됨
  • Spectre V1 취약점도 효율적 방식으로 차단, 대부분의 경우 실질적 공격 연결고리 차단 실현

소프트웨어·하드웨어 통합적 대응 및 범용 적용

  • 새로운 A19/A19 Pro 칩 설계 시, 태그 저장과 검증을 위해 추가적인 하드웨어 자원 대거 투입
  • MIE는 보안 할당자를 우선 활용하여 소프트웨어적으로 보호 가능한 부분을 감싸되, EMTE는 소프트웨어로 방어 불가능한 영역을 정밀하게 선정하여 적용
  • 구형 iPhone 기기도 가능한 한 많은 메모리 안전성 개선 혜택을 받을 수 있도록, 배포 방안 설계 정교화

실전 보안 평가 및 효과성 분석

  • Apple의 공격 연구팀이 2020~2025년 MIE 계획부터 다양한 공격 시나리오를 구성, 하드웨어 시제품까지 실제 침투 시도 반복
  • 신·구형 익스플로잇 체인 모두에서, MIE 적용 시 공격 단계 대부분이 근본적으로 봉쇄됨을 확증함
  • 살아남은 소수 취약점도 안정적 공격이 불가하여 실질적 피해 가능성 급감

결론

  • iPhone의 업계 최고 수준 보안은 대다수 사용자에게 시스템 레벨 공격 노출 자체를 제한함
  • MIE는 실제 용병형 스파이웨어의 가장 복잡하고 비싼 공격 전략을 무력화하면서, 커널 포함 주요 70여 사용자 영역 프로세스까지 항상 보호
  • 평가 결과, 메모리 손상 취약점의 익스플로잇 비용과 난이도를 대폭 상승시켜, 지난 25년간의 주된 공격 기법을 견고하게 차단하는 효과 확인
  • MIE는 iOS 및 Apple 디바이스에서 소비자 운영체제 메모리 안전성 사상 가장 큼 변화로 자리잡음
▲
GN⁺ 4일전  [-]
Hacker News 의견
  • 양쪽 접근 방식 모두 같은 결론에 도달했음. Memory Integrity Enforcement(MIE)은 공격자들이 사용할 수 있는 익스플로잇 전략의 대부분을 근본적으로 차단함. 메모리 오염 버그는 원래 서로 교환 가능하지만, MIE는 기본적인 단계에서 너무 많은 익스플로잇 경로를 차단해서 새로운 버그로 대체해도 체인을 복구할 수 없었음. 아무리 애써도 우회하는 체인을 재구성할 수 없었음. 남아 있는 몇몇 효과도 신뢰성이 없어서, 공격자가 성공적으로 악용하기엔 부족함. 이는 매우 좋은 소식이며, 언뜻 지나칠 수 있지만 중요한 포인트임. 용병형 스파이웨어 경제 구조 중 일부는 교환 가능한 체인에 의존하는데, 이런 속성을 직접 겨냥한 방어책은 특히 흥미로움
    • Apple의 전략이 CHERI(참조: Capability Hardware Enhanced RISC Instructions)와 같은 완전한 capability-based 메모리 안전으로 나아가는 단계인지, 아니면 Apple이 그런 시스템 없이도 충분하다고 판단했다는 신호로 봐야 하는지 궁금증이 듦
    • Apple 사례에 대응하는 Google의 메모리 안전 접근도 소개하고 싶음. Google은 Chrome/Android 초창기부터 메모리 안전에 진지했으며, ASAN, syzkaller, Hardware MTE 도입도 주도했음. 내가 이런 팀을 이끄는 책임자였기 때문에 여러 장단점을 직접 경험함. Google이 하려고 했던 바는 ASAN 수준의 검증을 필요에 따라 켜고 끌 수 있도록 하는 것이었음. 보안 대응책으로 항상 켜두는 방식은 메모리 오버헤드 외에도 여러 이슈가 있음. 예컨대, 모든 기기에서 일관되지 않게 사용자에게 눈에 보이는 크래시가 다수 발생하게 됨. 개발자 입장에선 100만 대 정도뿐인 MTE 지원 기기에서만 제대로 테스트해야 하므로 불만이 많아질 수밖에 없음. MTE로 잡히는 보안 익스플로잇도 있고, 무해한 버그도 다수 잡아냄. 다만, runtime mitigation 용으론 항상 최고의 선택인지는 불분명함. Google Security, Project Zero 등에서 CSVs 대응 노력을 매우 많이 하지만, MTE를 제품화하는 데 본사는 미흡했다고 느껴짐 (링크)
    • Vigilant Labs에게 좋은 소식이 아닐 수도 있겠지만, 실제로 큰 영향을 받았는지는 확실하지 않음
  • Apple의 "메모리 안전 보호는 반드시 항상 동기적으로, 기본적으로 켜져 있고, 지속적으로 동작해야 함"이라는 주장은 원리주의에서라기보다 경험에서 나왔으리라 생각함. 이는 초기 커널 보호와는 달랐음. 2015년 iOS 9에서 도입된 Kernel Patch Protection(KPP)은 커널이 수정됐는지 몇 분에 한 번, 기기가 한가할 때 비동기적으로 체크하는 방식이었음. 이 방식은 보안적으로 그리 신뢰할 만하지 않았고, 디자인 결함이 있어 완전 우회하는 해킹이 발표됐었음. KPP는 커널 패치를 원천적으로 막지 않고, 탐지됐을 때 패닉을 유발할 뿐임. 즉, 공격자가 작업을 충분히 빠르게 끝내고 되돌리면 KPP가 감지 못하는 구조였음 (writeup 참고)
    • 내부 정보를 기반으로, KPP는 A11의 KTRR이 도입될 무렵 <A11 SoCs 상에서 동등한 보안 수준을 일부러 맞추기 위해 급하게 만들어졌음. 이와 같은 단기 타임라인에서 최선의 방식으로 구현됐으며, 이후엔 이런 방식을 반복하지 않았음
    • 처음부터 원칙적으로 준비했다기보다, MTE 도입을 위해 첫 기획 때 이런 결론에 도달한 것으로 보임. Apple의 보안 수준은 꾸준히 향상되고 있고, 그 배경에는 탈옥 등으로 인해 강제로 배운 경험들이 큼
    • 이런 시스템은 처음부터 완벽하게 구현하는 게 어렵다는 점은 공감함
  • Apple은 “아이폰에 대해 성공적이고 광범위한 악성코드 공격은 없었음”이라고 했지만, 기존 스파이웨어 코드가 약간만 수정돼도 바로 대규모 공격에 쓰일 수 있다 생각함. 실제로 이러한 구분이 그리 명확하지 않음
    • Apple, Google 어느 쪽도 실제 공격 규모에 대해 완벽히 파악할 수 없는 게 현실임. GrapheneOS가 공개한 유출 자료에 따르면, 익스플로잇 개발자들은 사람들이 생각하는 것 이상으로 기기 공격과 업데이트 대응에 능함. 추가로 공개하지 않은 자료도 있으며, 여러 독립 출처로 검증되지 않으면 유출 경로 노출 방지를 위해 일부만 공유함. 이런 익스플로잇 도구는 널리 사용 가능하고, 일상적 데이터 추출인지 원격 악용인지 구별조차 쉽지 않음. 실전에서 익스플로잇이 탐지되는 경우는 드물고, 대부분은 탐지 없이 대규모 사용이 가능하기에 단일 체인도 장기간 가치가 있음. 전 세계 법 집행기관이 Cellebrite Premium 같은 도구를 사용하여 국경, 시위 현장 등에서 많은 사람들에게 적용 중임. 이는 이미 대규모 사용에 해당함. 원격 익스플로잇의 경우는 넓게 사용돼도 넓게 배포할 필요조차 없음
    • XcodeGhost는 아이폰 대규모 악성코드 공격의 대표적 사례임. 당시 WeChat 등이 감염됐음. 참고 자료: XcodeGhost 위키피디아
    • 실제 대규모 공격에 사용될 수 있었는지는 확실하지 않지만, Windows처럼 노출도가 높았다면 사례가 많았을 것임
    • 해당 문구는 주로 Android와 비교해 자사 통제 모델의 장점을 강조하려는 의도가 있을 수 있음
    • 변호사식 언어이긴 하지만, 이번 MIE 등 신기술에 대해 Apple이 매우 자세한 자료와 자신감 있는 메시지를 내놓은 점은 우리 모두에게 긍정적임
  • 이번 시스템은 확실히 인상적임. 다만, 공격자가 여러 번 재시도할 수 있는 경우엔 방어가 충분치 않을 수 있음. 예를 들어, 인접하지 않은 객체까지 벗어난 접근이 가능하거나, 많은 메모리 할당 조작 끝에 우연히 태그가 맞으면 우회 가능함. 태그가 맞을 확률은 1/16임. 다만 본문에 자세한 설명이 없어 내 예측이 맞는지 확실치 않음. 만일 성공적으로 적용된다면, 남은 익스플로잇은 로직 버그에 의존해야 해 공격자 입장에선 훨씬 어려워질 것임
    • Android MTE에서도 비슷하게, 작은 태그 크기 문제를 노린 확률적 공격(여러 번 재시도)이 가능했음. 다만, 중요한 차이는 여기서 일관된 동기적 enforcement가 핵심임. 즉, 바로 메모리 쓰기 조작마다 trap이 뜨고 컨텍스트 스위치 때가 아님
    • 1/16 확률 외의 15/16 시도는 모두 크래시를 유발함. 이렇게 불안정한 버그는 사용자나 진단 시스템에 노출되기 쉽고, 여러 단계를 이어서 성공해야 한다면 확률적으로 실제 악용은 거의 불가능에 가까움
    • 공급망 공격 등, 오랜 시간을 들여 침투하는 국가 단위 공격엔 이런 방어책이 적용되지 않을 수도 있음
  • Apple/ARM의 모델은 훨씬 더 정교하겠지만, Burroughs large system의 메모리 태깅 아키텍처가 연상됨 (참고)
  • “공격자가 시스템이 선택하는 태그 값을 예측하지 못해야 한다. 이를 위해 자주 PRNG를 리시드해서 새 태그를 생성한다”는 설명에서, 근본 문제는 태그의 낮은 엔트로피(단 4비트임)임. 공격자가 무작위로 맞추면 성공 가능성이 1/16인데, PRNG 리시드로 그 확률이 바뀌진 않음. 추가 설명이 필요해 보임
    • 공격자는 단 한번 추측 기회만 가짐. 틀리면 프로세스가 종료되거나 커널이 패닉남. 다음에 시도할 땐 새로운 태그라 다시 추측해야 하므로 연속 시도가 불가능함
    • 4비트면 가능한 경우의 수가 너무 적음. 메모리 할당은 초당 수백만 번 발생하고, 리시드가 잦더라도 충돌 가능성은 매우 빠르게 높아짐
  • 이번 시리즈 기기의 최대 강점은 바로 이 새로운 기능임
  • EU의 chat control 같은 정책이 시행되면 국가가 내 디바이스에서 원하는 모든 것에 접근할 수 있고, Google이 WEI를 강제하면 웹 전체가 막힐 수 있음. Secure boot와 MIE가 도입되면 사용자가 기존의 자유를 다시 찾는 게 어려워질 수 있음
    • 즉, 이런 자유를 지키려면 시스템과 서비스를 좀 더 분리(발칸화)해야 할 것임
    • 여기서 MIE 강화가 탈옥(jailbreak) 등 사용자의 자유를 제한한다는 불만이 포함된 것인지 궁금함
    • WEI가 무엇인지 궁금증이 듦
  • Google이 작년 MTE를 opt-in으로 제공한 것은 좋은 첫걸음이지만, 완전한 통합이 부족해서 Apple이 강조하는 EMTE 기반 MIE와는 다름. Apple의 iPhone 17과 Air 출시로 산업 최초의 종합적 항상 켜진 메모리 안전 시스템이 도입되는 점이 인상적임. 비록 GrapheneOS의 선도적 노력(릴리즈 예시, 인식 제고)이 제대로 조명받지 못한 건 아쉽지만, Apple의 진지한 시도가 Google, Pixel OS, 그리고 여러 보안 OS에 빨리 확산되길 희망함. GrapheneOS는 알려지지 않은 위협까지 방어하는 시스템 선도자임을 다시 확인함
    • Apple은 이 분야에서 오랜 기간 준비해왔음. GrapheneOS에서 활성화한 시점부터 시작한 것은 아님
  • “2018년 A12 Bionic 칩에 Pointer Authentication Codes(PAC)를 업계 최초 적용해 코드 플로우 무결성 보호에 나섰다”는 문구가 있지만, PAC 도입 이후에도 풀 체인 공격 사례가 여러 번 있었음. PAC은 의미 있는 공격 억제 수단이 아니었음. 공격자는 계속 PAC 우회를 찾아내고 있음. 이 점을 MIE의 실효성 판단에 감안해야 함
    • 사실 Apple은 PAC을 공격 억제책이라고 하지 않았고, "익스플로잇 복잡도 증가"가 성과라고 말했음. 문장 자체는 다소 모호하지만, 내가 읽기엔 PAC만으로는 부족해 SW/HW 결합 접근이 필요하다는 인정으로 보임. PAC 자체도 SW 변경이 필요한 HW 기능이지만, EMTE는 훨씬 더 넓은 면적과 조정이 필요한 기술임
    • PAC이 의미가 없다는 게 아니라, 오히려 공격자로 하여금 PAC 우회책을 반드시 찾게 만드는 촉진제 역할을 함. PAC 우회책은 무한정 많지 않음
    • PAC이 여러 번 우회됐다고 해서 무효란 건 아니며, 그만큼 효과적으로 작동하고 있음
답변달기