Apple MIE를 흔든 검증 코드 하나
제목 : Apple MIE도 뚫렸다, CVE-2026-28952가 남긴 보안 교훈
Apple이 5년간 설계한 메모리 보호 체계도 결국 작은 검증 로직 하나에서 흔들렸어요.
이번 사례는 “하드웨어 보안이면 충분하다”는 생각에 다시 질문을 던지게 합니다.
1. Apple MIE, 무엇을 막으려 했나
MIE(Memory Integrity Enforcement)는 Apple Silicon 기반 기기에서 커널 메모리 공격을 어렵게 만들기 위한 보안 구조예요. 핵심 목표는 메모리 버그가 있어도 공격자가 이를 실제 권한 상승으로 연결하지 못하게 막는 것입니다.
MIE는 크게 세 가지로 구성돼요. EMTE는 메모리 태깅(메모리와 포인터에 숨은 라벨을 붙여 접근을 검증하는 기술)으로 잘못된 포인터 접근을 차단합니다. RO Zone은 ucred, task_t, 코드서명 상태처럼 중요한 커널 구조체를 읽기 전용 영역에 보관해요.
여기에 SPTM(Secure Page Table Monitor)이라는 더 높은 권한의 감시자가 붙습니다. 커널조차 마음대로 페이지 테이블을 바꿀 수 없고, 오직 승인된 함수인 _zalloc_ro_mut만 RO Zone을 잠깐 쓰기 가능하게 만들 수 있어요.
2. CVE-2026-28952, 문제는 ‘문지기’ 안에 있었다
이번 취약점 CVE-2026-28952는 Apple이 macOS Tahoe 26.5에서 패치한 커널 취약점이에요. Calif.io 팀은 Anthropic의 AI 모델과 함께 M5 + MIE 환경에서 5일 만에 로컬 권한 상승 공격을 구현했다고 공개했습니다.
핵심은 _zalloc_ro_mut 함수의 **정수 오버플로우(integer overflow, 계산 결과가 표현 범위를 넘어 다시 작은 값으로 돌아가는 현상)**였어요. 이 함수는 RO Zone에 데이터를 쓰기 전 target + len으로 쓰기 범위를 검사하는데, 특정 경로에서 이 계산이 오버플로우 검증 없이 먼저 사용됐습니다.
그 결과 실제로는 매우 큰 길이의 쓰기가 발생할 수 있는데, 검증 로직은 오버플로우로 작아진 값을 보고 “문제없다”고 판단할 수 있었어요. 중요한 점은 MIE의 태그, 읽기 전용 페이지, SPTM이 모두 정상 동작했다는 것입니다. 문제는 그들이 신뢰하는 유일한 쓰기 함수의 입력 검증에 있었어요.
3. 왜 이 취약점이 위험했나
이 버그가 위험한 이유는 공격 대상이 일반 메모리가 아니라 커널의 핵심 권한 정보가 담긴 RO Zone이기 때문이에요. 예를 들어 ucred 구조체에는 프로세스의 사용자 ID 정보가 들어 있고, 여기서 cr_uid 값이 0이면 root 권한으로 인식됩니다.
즉 공격자가 인접한 ucred 구조체의 일부 값을 바꿀 수 있다면, 코드 실행이나 복잡한 페이로드 없이도 프로세스가 root처럼 동작할 수 있어요. 이른바 데이터 전용 공격(data-only exploitation, 코드가 아니라 중요한 데이터만 바꿔 권한을 얻는 방식)에 가까운 형태입니다.
다만 이 취약점은 원격 코드 실행이 아니라 **로컬 권한 상승(LPE)**에 해당해요. 이미 사용자의 기기에서 코드가 실행되는 상황이 필요하므로, 피싱·악성 앱·초기 침투를 막는 보안 통제가 여전히 중요합니다.
4. Apple의 패치가 바꾼 것
Apple의 패치는 작지만 의미 있는 변경이었어요. macOS 26.5에서 _zalloc_ro_mut의 검증 순서를 바꾸고, 위험했던 스택 영역 검사 로직을 제거했으며, TPIDR_EL1 기반의 per-CPU 경계 검사를 추가했습니다.
핵심 변경은 다음과 같이 볼 수 있어요.
오버플로우 검사를 더 앞에서 수행
target + len이 감싸 돌아가는지 먼저 확인해, 잘못된 값이 범위 비교에 쓰이지 않도록 했습니다.per-CPU RO sub-zone 경계 검사 추가
CPU별 읽기 전용 하위 영역을 벗어나지 않는지 확인해, 검증 범위를 더 촘촘하게 만들었습니다.취약했던 stack-area filter 제거
오버플로우된 값을 정상 범위처럼 통과시키던 우회 경로를 없앤 것이 가장 직접적인 수정입니다.
하지만 이것이 취약점 계열 전체를 끝낸 것은 아니에요. _zalloc_ro_mut_atomic, 코드서명 플래그 변경 함수, 샌드박스 슬롯 갱신 함수 등 다른 “신뢰받는 writer”들도 비슷한 검증 구조를 갖고 있다면 다음 공격 표면이 될 수 있습니다.
5. 보안 담당자와 개발자가 지금 할 일
기업 보안 담당자라면 가장 먼저 패치 적용 여부를 기기별로 검증해야 해요. 자동 업데이트가 켜져 있다고 안심하기보다 MDM으로 macOS, iOS, iPadOS 빌드 번호를 확인하는 것이 안전합니다.
특히 다음 버전으로 업데이트됐는지 확인해야 합니다.
macOS Tahoe 26.5
M5 기반 Mac에서 MIE 우회 이슈와 직접 연결되는 업데이트입니다.macOS Sequoia 15.7.7,macOS Sonoma 14.8.7
RO Zone 구조가 도입된 구버전 Apple Silicon 환경도 영향권에 포함됩니다.iOS 18.7.9,iPadOS 18.7.9
모바일 기기도 동일 계열 패치가 제공됐으므로 고위험 사용자부터 우선 적용하는 것이 좋습니다.
개발자 관점에서는 교훈이 더 분명합니다. 보안 기능 자체보다 그 보안 기능을 호출하는 검증 코드가 새로운 공격 표면이 될 수 있어요. 범위 검사, 길이 계산, 포인터 산술이 들어간 코드에서는 “계산 후 검사”가 아니라 “검사 후 계산”이 되는지 반드시 점검해야 합니다.
마무리하며
이번 사건은 MIE가 실패했다기보다, 강력한 방어 체계도 신뢰 경계의 작은 틈에서 우회될 수 있다는 사실을 보여줍니다. 메모리 태깅과 하드웨어 보호는 분명 큰 진전이지만, 마지막으로 문을 여는 함수의 입력 검증이 틀리면 전체 구조가 흔들릴 수 있어요.
Apple 기기를 운영한다면 지금은 업데이트를 미룰 때가 아닙니다. 그리고 보안 아키텍처를 설계하거나 리뷰하는 입장이라면, “가장 신뢰받는 함수가 가장 위험한 공격 표면이 될 수 있다”는 점을 꼭 기억해야 합니다.
