EX-ARRR: Apple 제로클릭 취약점의 경로를 추적하다

AI 요약

IronPeak의 연구자는 Apple 기기의 OpenEXR 디코더에서 발견한 메모리 손상 취약점이 iMessage를 통한 제로클릭 공격으로 이어지는 과정을 설명합니다. 취약점은 Apple의 이미지 처리 라이브러리인 libAppleEXR.dylib에 있습니다. 디코더는 RGB 세 채널을 기준으로 픽셀당 12바이트를 할당하지만, 실제 인터리브 루틴은 알파 채널까지 포함해 픽셀당 16바이트를 씁니다. 448×448 이미지에서는 할당 영역을 크게 넘어서는 힙 쓰기가 발생합니다.

퍼저가 찾은 불일치

연구자는 무작위 바이트를 넣는 대신, 디스어셈블리를 읽은 LLM이 파일 구조와 코드 분기 조건을 분석해 변형을 제안하는 방식으로 퍼징했습니다. 이 과정에서 채널 수에 맞춘 버퍼 할당과 네 채널을 쓰는 루프 사이의 불일치를 발견했습니다. 정적 분석만으로는 취약점이라고 단정하지 않고, 작은 EXR 파일을 만들어 ImageIO 디코더에 넣어 실제 충돌을 확인했습니다. ARM NEON 명령어와 충돌 주소를 분석해 12바이트 할당 뒤에 16바이트 쓰기가 이어진다는 점도 검증했습니다.

쓰기 값의 상당 부분은 파일에서 지정한 RGB 픽셀 값입니다. 알파 채널은 1.0으로 고정되지만, 나머지 세 채널 값은 톤 매핑 과정을 거쳐도 예측 가능한 관계를 유지합니다. 연구자는 이미지 크기와 힙 배치를 반복해서 조정하고, 실제 Photos 앱의 파일 가져오기 경로를 AppleScript로 실행해 주변 힙 객체에 쓰기가 닿는 조건을 찾았습니다. 그 결과 오버플로 위치를 일정하게 만들고, 공격자가 고른 값을 이웃 객체에 반영할 수 있음을 보였습니다.

iMessage에서 사용자 조작 없이 실행

공격 경로는 메시지 앱에서 첨부 파일을 직접 열 때만 작동하지 않습니다. iMessage로 파일이 도착하면 시스템이 검색 색인과 미디어 썸네일을 준비하면서 백그라운드에서 이미지 디코더를 실행합니다. 사진 라이브러리의 처리 경로가 표준 동적 범위(SDR) 옵션을 지정하고, 이 옵션이 취약한 디코드 루틴을 호출합니다. 따라서 사용자가 메시지를 열거나 첨부 파일을 누르지 않아도 백그라운드 처리 중 취약점이 실행됩니다. 기기에서 수집한 충돌 기록도 포그라운드 입력 없이 백그라운드 작업 중 디코더가 실패한 사례를 보여줬습니다.

연구자는 BlastDoor가 EXR 형식을 처리하지 않으며, 문제가 되는 디코딩이 메시지 파싱 단계가 아니라 이후 색인과 썸네일 생성 과정에서 일어난다고 설명합니다. 즉, 첨부 파일이 BlastDoor의 처리 경로를 지나지 않고 뒤이은 이미지 처리 경로에서 디코딩됩니다. 같은 libAppleEXR와 ImageIO 코드가 iOS, iPadOS, macOS에 들어 있어 세 플랫폼 모두 영향 범위에 포함된다고 보고합니다.

익스플로잇 가능성과 방어책

연구자는 힙 배치를 조정해 임의 쓰기까지 확장했고, 통제된 테스트 하네스에서는 함수 포인터를 덮어 프로그램 카운터를 원하는 곳으로 돌리는 데 100회 중 100회 성공했다고 밝혔습니다. 다만 실제 기기의 프로세스 경계를 넘는 코드 실행에는 제약이 남습니다. Pointer Authentication(PAC)이 함수 포인터를 보호하므로 유효한 포인터를 만들 정보 유출이 필요합니다. 최신 하드웨어 일부에서는 취약점이 실행되는 특권 데몬에 하드웨어 메모리 태깅도 적용돼 쓰기가 태그 검사 오류를 일으킵니다. 그러나 Photos 포그라운드 프로세스에는 해당 보호가 적용되지 않았고, 이전 세대 기기에도 메모리 태깅이 없다고 설명합니다. 따라서 하네스에서 확인한 코드 실행과 실제 피해 기기에서 완성한 코드 실행을 구분해야 합니다. 글은 Apple이 보고를 iMessage EXR 페이로드를 통한 제로클릭 코드 실행으로 분류하고 수정 사항을 배포했다고 전합니다.

개발·보안 관점의 교훈

글은 이미지 썸네일러, 검색 색인기, 미디어 분석기처럼 도착한 콘텐츠를 자동 처리하는 경로를 공격 표면으로 살펴야 한다고 강조합니다. 널리 쓰이는 JPEG·PNG뿐 아니라 ImageIO가 지원하는 덜 알려진 형식도 점검 대상입니다. 버퍼를 할당한 크기와 실제 쓰기 크기를 일치시키는 검증이 필요하며, 백그라운드 데몬의 이미지 파서 충돌을 단순 안정성 문제로 취급해서는 안 된다고 덧붙입니다. 또 하네스는 실제 프로세스의 권한과 힙 상태, 입력 경로를 재현하지 못할 수 있으므로 실제 시스템의 처리 경로에서 검증해야 한다고 설명합니다.

Reddit 반응

• @u/SirensToGo — 솔직한 단서가 글을 읽기 괴롭게 만드는 결정적인 지점입니다.
  • @u/SavingsMany4486 — X도 없고 Y도 없는, 그저 엉성한 글입니다. 솔직하네요.
  • @u/hordak666 — 똥은 없고 방귀만 있네요.
• @u/No-View3333 — 실제 iMessage로 촉발된 데몬에서 코드 실행에 성공했나요, 아니면 테스트 하네스에서만 성공했나요?
  • @u/nindustries — 최종 PoC에는 테스트 하네스가 없었으니, 네, 자체적으로 터졌습니다.
• @u/rob94708 — AI가 쓴 글은 읽기가 정말 힘드네요. ‘솔직히’라는 단어를 한 번만 더 보면…
  • @u/BreiteSeite — 그 지적이 맞습니다. 제가 더 분명하게 썼어야 했습니다…
  • @u/TamerlanMcDoodles — AI 글이라기보다는 영어를 제2언어로 쓰는 사람이 쓴 글 같네요.
• @u/petermal67 — 버그 바운티 얘기가 없네요? 궁금합니다.

원문: IronPeak / 번역·요약: Trawling