Apple M5에서 첫 공개 macOS 커널 메모리 손상 익스플로잇
요약
본 기사는 Apple M5에서 발견된 macOS 커널 메모리 손상 익스플로잇을 다루며, 이 취약점이 높은 가치를 지닐 수 있음을 시사합니다. 또한, LLM이 생성하는 코드의 무분별한 배포와 그로 인한 개발 프로세스의 보안 위험 증가에 대한 우려를 제기합니다. 기술적으로는 Memory Tagging Extension (MTE)가 개입해야 할 동작을 강제하지 않는 'data-only' 공격 경로 및 fbounds 검사 적용 여부 등 심도 있는 분석이 이루어지고 있습니다.
핵심 포인트
- Apple M5에서 발견된 macOS 커널 메모리 손상 익스플로잇은 높은 보안 가치를 지닐 수 있음.
- LLM 생성 코드의 무분별한 사용과 개발 프로세스의 취약성이 증가하고 있으며, 이는 심각한 보안 위험을 초래함.
- Memory Tagging Extension (MTE)는 메모리 접근 시 비밀값을 검사하여 손상 버그를 식별하는 하드웨어 기반 방어 기제임.
- 이론적으로 완벽하게 안전한 시스템 구축은 어려울 수 있으며, 과거의 보안은 '모호성'에 의존했을 가능성이 있음.
- Apple은 Swift 언어를 Safari CSS 파서 및 Secure Enclave 등 여러 영역에서 실제로 사용하고 있으며, fbounds 검사 도입을 강력히 추진하고 있음.
시연 내용만 보면 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가 많은 공격 경로를 줄이긴 하지만 유용한 손상 원시 동작을 전부 없애지는 못한다는 교훈일 수 있음
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나 대안 언어 채택이 더 늘어나는 것도 보고 싶고, 안전한 언어 영역에 더 많은 경쟁이 생기는 건 언제나 환영할 만함
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기