안드로이드 단말을 겨냥한 새로운 공격 시나리오가 공개됐다. 조작된 WAP Push SMS 한 통만으로 통화 처리를 담당하는 시스템 프로세스 com.android.phone를 강제 종료시켜, 피해자가 아무런 조작을 하지 않아도 진행 중이던 통화가 끊기는 이른바 제로클릭(zero-click) 원격 서비스 거부(DoS) 공격이다. 공격자는 피해자의 전화번호만 알면 되고, 피해자 화면에는 아무것도 표시되지 않는다는 점에서 기존의 단순 크래시 버그와는 성격이 다르다.
정수 캐스팅 한 줄에서 시작된 문제
기술적 원인은 의외로 단순하다. 안드로이드가 WAP Push 메시지를 받으면 WapPushOverSms.decodeWapPdu()가 WSP 헤더 길이를 uintvar 형식으로 읽는다. 이 값은 long으로 반환되지만 범위 검사 없이 int로 캐스팅된 뒤 그대로 새 바이트 배열의 크기로 사용된다. 공개된 분석에 따르면 5바이트 uintvar 값 88 80 80 80 00은 0x80000000으로 해석되고, 이를 부호 있는 32비트 정수로 변환하면 -2147483648이 된다. 즉 new byte[-2147483648]를 할당하려다 NegativeArraySizeException이 통신 처리 메인 스레드에서 처리되지 않은 채 발생하고, 그 결과 com.android.phone가 죽는다. 이 메시지는 데이터 SMS로 전달되기 때문에 수신함에 남지 않으며 발신 번호도 노출되지 않는다.
보고서는 Pixel 9(2026년 4월 펌웨어), 여러 삼성 갤럭시 및 A 시리즈 등 제조사와 모델을 가리지 않고 100% 재현됐다고 밝힌다. 안드로이드 통신 스택이 공유하는 공통 코드에서 비롯된 문제라는 점에서 특정 기기만의 결함으로 보기 어렵다.
일시적 장애에서 영구적 벽돌로
정작 위험한 부분은 반복 전송 시 나타난다. 메시지 한 통은 통신 기능의 일시적 중단에 그치지만, 약 30통을 빠르게 연속 전송하면 크래시가 통신 공급자의 SMS 저장소 기록 작업과 맞물리면서 경쟁 조건(race condition)이 발생하고, 문자 메시지를 담은 SQLite 데이터베이스가 손상된다. 일단 DB가 깨지면 com.android.phone는 새 메시지 없이도 부팅할 때마다 손상된 저장소를 읽다가 즉시 크래시한다. 재시작해도 복구되지 않는, 사실상 통신 기능이 영구 마비된 상태가 되는 것이다.
복구 과정은 더 가혹하다. 공장 초기화를 해도 통신사가 아직 확인응답(ACK)을 받지 못한 페이로드를 다시 보내 크래시를 재유발하기 때문에 일시적 효과에 그친다. 물리 SIM이라면 다른 단말로 옮겨볼 여지라도 있지만, eSIM 사용자는 그런 우회가 불가능해 복구 난도가 크게 올라가고, 비전문 사용자에게는 사실상 자력 복구가 불가능한 수준이라는 지적이다.
긴급통화와 규제가 만드는 역설
이 취약점이 단순 불편을 넘어서는 이유는 긴급통화에 있다. 공격이 진행 중이거나 DB 손상으로 단말이 먹통인 동안에는 호주의 긴급번호 000으로도 전화를 걸 수 없다. 보고서는 이를 호주 VRP 규정상 '파괴적 원격 DoS(Destructive Remote DoS)'의 전형으로 규정한다. 더 나아가 규제 구조가 역설을 만든다. 호주 ACMA가 운영하는 긴급통화서비스 결정(Emergency Call Service Determination)은 통신사가 000에 접속할 수 없는 단말을 식별해 사용자를 정상 단말로 이전시키고, 해당 기기에 대한 서비스 제공을 중단하도록 의무화한다. 텔스트라는 000 통화가 불가능해진 단말을 차단해야 하며, 조치가 없으면 28일 내 차단한다고 명시한다. 결국 공격자가 원격으로 이 상태를 유도하면, 피해자의 단말이 통신사 망에서 차단되도록 만들 수 있다는 뜻이다. 이 틀은 3G 종료로 일반 통화는 되지만 긴급통화가 안 되는 단말이 생긴 문제를 계기로 2024년 강화됐는데, 이번 취약점이 바로 그 상태를 인위적으로 재현한다.
수정은 간단하지만 처리는 지연됐다
해법 자체는 명확하다. WapPushOverSms.java 217번째 줄에서 캐스팅 전에 범위 검사를 추가하면 되고, 보고자는 최초 보고 당일 이 수정안을 구글에 제공했다고 밝혔다. 그러나 이 건은 Android & Google Devices VRP를 통해 비공개로 접수되고 오분류 이의제기로 두 차례 재제출됐음에도, 세 개의 티켓과 네 명의 엔지니어를 거치며 '보안 이슈가 아님'으로 분류됐다. 90일 공개 기한을 넘겨서도 수정이 이뤄지지 않자, 보고자는 사용자·통신사·하류 OEM이 위험을 평가하고 완화할 수 있도록 전체 공개(full disclosure)로 전환하고 PoC 앱과 전체 소스를 깃허브에 Apache 2.0 라이선스로 공개했다.
한국 실무자 입장에서 이 사례는 두 가지를 시사한다. 하나는 신뢰할 수 없는 외부 입력을 다루는 파싱 코드에서 정수 변환과 배열 할당 사이의 범위 검증이 여전히 치명적 공백으로 남을 수 있다는 점이고, 다른 하나는 기술적 취약점의 영향이 규제 체계와 결합할 때 전혀 다른 차원의 피해로 증폭될 수 있다는 점이다. 다만 공개된 자료는 공격자 관점의 분석과 PoC에 집중돼 있어, 실제 기기별 재현 조건이나 통신사 네트워크 구성에 따른 편차, 구글의 공식 입장은 확인되지 않은 상태다. PoC는 작동하는 공격 도구인 만큼, 본인 소유이거나 명시적으로 허가받은 기기에 대한 방어·연구 목적으로만 다뤄야 한다.