안드로이드에서 사용자가 설치하는 모든 서드파티 앱은 untrusted_app이라 불리는 샌드박스 안에서 돌아간다. 이 격리된 환경에서 시스템 최고 권한인 root까지 도달하는 방법을 공격 보안 연구자 다섯 명에게 물으면 대개 다섯 가지 다른 전략이 돌아온다. 보안 연구 사이트 calif.io가 공개한 'OEMpocalypse' 연재의 1편은 그중에서도 제조사(OEM)가 직접 작성한 코드만을 표적으로 삼는 단일 전략을 제시한다. 이 전략 하나로 삼성 갤럭시 S23~S26 및 최근 Z 시리즈 전 기종, 샤오미의 중급기부터 플래그십까지 상당수, 그리고 오포·원플러스·리얼미의 최신 플래그십을 아우르는 권한 상승 체인을 구성했다는 것이 글의 골자다.
세 겹의 방어벽과 공격 표면
앱이 커널에서 건드릴 수 있는 범위가 좁은 이유는 세 가지 방어 계층이 겹쳐 있기 때문이다. 앱마다 별도 UID를 부여하는 유닉스 재량적 접근 제어(DAC), 그 위에서 접근 가능한 장치 노드·소켓·경로를 제한하는 SELinux 강제 접근 제어(MAC), 그리고 호출 가능한 시스템 콜 일부를 차단하는 seccomp 필터가 그것이다. 이 세 가지가 합쳐져 커널 대부분, 특히 드라이버 계층 대부분은 더 높은 권한의 도메인으로 이동하지 않으면 아예 손이 닿지 않는다. 결국 untrusted_app에서 시작할 때 실제로 노릴 수 있는 커널 표면은 크게 세 부류로 나뉜다. 모든 기기가 공유하는 업스트림 리눅스와 안드로이드 공통 커널(ACK), 성능을 위해 앱에 직접 노출된 칩셋 드라이버, 그리고 제조사 고유 코드다.
왜 '범용 버그'가 아니라 제조사 코드인가
연구자는 무기화된 익스플로잇을 세 가지 잣대로 평가한다. 방어 설정과 무관하게 거의 100% 성공하는 신뢰성, 커널 버전·제조사·칩셋별 조정이 최소인 이식성, 그리고 하나의 익스플로잇이 최대한 많은 기기를 덮는 보편성이다. 이론상 가장 보편적인 것은 리눅스 공통 코드의 버그다. io_uring이나 메모리 관리 코어의 결함은 제조사와 칩셋을 가리지 않으며, 실제로 여러 제조사 기기를 한 번에 루팅한 IonStack 같은 인상적인 사례도 있다. 그러나 여기서 얻는 원시 조작 능력은 대개 슬랩 수준의 특정 객체 UAF나 제한된 범위 초과 쓰기에 그쳐, 힙 그루밍과 크로스 캐시, 정보 유출 같은 기법을 겹겹이 쌓아야 root에 닿는다. 게다가 커널 버전(5.15~6.12), 제조사가 덧댄 패치와 런타임 설정(삼성의 RKP·KDP, mem-cg 활성화 여부), RAM 용량과 코어 수에 따라 달라지는 개별 기기의 할당자 동작이라는 세 축의 변수를 한 익스플로잇이 동시에 견뎌야 한다. 버그 자체는 어디에나 있지만, 안정적이고 이식성 있는 익스플로잇으로 만드는 데 노력이 집중되는 구조다.
GPU(말리, 아드레노 KGSL, 파워VR)나 DSP·NPU 드라이버는 사정이 조금 다르다. 이들은 사용자 데이터를 처리하려고 물리 페이지를 고정하고 장치 페이지 테이블에 매핑했다가 해제하는 일을 하기 때문에, 수명 관리 실수가 곧 페이지 단위 조작 능력으로 이어지는 경우가 많다. 다만 한 버그가 덮는 기기 범위는 칩셋에 따라 천차만별이다. 퀄컴 공통 코드인 adsprpc나 KGSL의 버그는 여러 스냅드래곤 세대와 여러 제조사를 넘나들지만, 특정 말리·엑시노스 IP 블록에 묶인 버그는 훨씬 좁다. 게다가 칩셋 경계는 제조사 경계와 어긋난다. 삼성만 해도 지역에 따라 엑시노스와 스냅드래곤을 병행 출시하므로 칩셋 버그 하나가 한 제조사 라인업 전체에 대응하는 일은 드물다.
소프트웨어 계층에 묶인 코드의 매력
반면 제조사 고유 코드는 원 UI, 하이퍼OS, 컬러OS 같은 소프트웨어 계층에 묶여 있어 그 아래 칩셋이 스냅드래곤이든 엑시노스든 디멘시티든 동일하게 존재한다. 제조사당 버그 하나가 원리상 해당 부품을 탑재한 모든 모델에 닿는, 바로 그 보편성이 이 전략의 노림수다. 핵심 아이디어는 제조사 드라이버에서 페이지 UAF를 찾되, SELinux 정책이 직접 접근을 막는 경우에만 샌드박스 탈출을 앞단(스테이지 1)으로 두는 것이다. 안드로이드의 격리는 절대적이지 않아, 바인더 호출·인텐트·콘텐츠 프로바이더·로컬 소켓 같은 프로세스 간 통신(IPC) 창구가 곳곳에 있다. 제조사는 AOSP 위에 자체 앱과 서비스, 네이티브 데몬을 대거 얹으면서 이런 창구를 늘리는데, 그중 하나에 호출자 검증 누락이나 부적절하게 노출된 컴포넌트, 검증 없는 파일 경로 같은 논리 결함이 있으면 권한 경계를 넘을 수 있다.
실무적으로 이 연구가 시사하는 바는 분명하다. 그동안 안드로이드 LPE 연구와 실제 공격은 untrusted_app에서 곧장 닿는 GPU·DSP 드라이버에 집중돼 상당히 체계적으로 감사됐지만, 더 높은 권한 도메인 뒤에 숨은 제조사 고유 코드는 상대적으로 덜 들여다본 영역으로 남아 있었다. 이 결함이 칩셋이나 커널 버전이 아니라 제조사 소프트웨어 계층에 종속된다는 점은, 방어자 입장에서 패치 대상과 위험 노출 범위가 기기별이 아니라 소프트웨어 브랜드별로 묶인다는 뜻이기도 하다. 다만 이 1편은 전략의 논리와 대안 비교에 머물러 있고, 구체적인 샌드박스 탈출 기법과 드라이버 버그의 세부는 이후 제조사별 후속 글로 미뤄져 있다. 개별 취약점의 CVE나 패치 현황, 재현 조건 같은 검증 가능한 세부가 아직 공개되지 않은 만큼, 현 단계에서는 확정된 위협 목록보다는 공격 표면을 바라보는 하나의 관점으로 읽는 편이 타당하다.