요약
문자 한 통으로 안드로이드 폰의 통신을 끊고 긴급 통화까지 막는 제로 클릭 DoS 버그가 공개됐습니다.
보안 연구자 마크 B가 쓴 분석 글입니다. 5월에 구글에 신고했고, 10월 안드로이드 보안 업데이트로 수정이 나온 뒤 10월 29일에 글과 개념 증명 앱을 공개했습니다.
왜 중요한가
- 사용자가 아무것도 누르지 않아도 전화번호만으로 통화와 통신을 끊을 수 있습니다.
- 진행 중인 긴급 통화도 끊기기 때문에 단순한 오류를 넘어 안전 문제가 됩니다.
- 수정은 안드로이드 14~17에만 적용되어, 업데이트 기간이 끝난 12·13 기기는 계속 취약합니다.
핵심 내용
decodeWapPdu()가 헤더 길이를 범위 확인 없이 배열 크기로 쓰다가 음수가 되면com.android.phone이 죽습니다.- 메시지는 WAP 푸시(화면에 표시되지 않는 데이터 문자)로 오므로 알림도 발신 번호도 보이지 않습니다.
- 처리되지 못한 메시지가 부팅 때마다 다시 읽혀 약 90초 간격의 재부팅이 반복될 수 있습니다.
- 통신사도 메시지를 재전송해서, 시험에서는 한 통으로 최대 일주일간 간헐적 장애가 이어졌습니다.
- 복구하려면 컴퓨터와 ADB(안드로이드 디버깅 도구)로 부팅 직후 메시지를 지워야 하며, 일반 사용자는 공장 초기화까지 갈 수 있습니다.
HN 반응
- 구글이 신고를 수정 불필요로 닫은 것은 심사나 소통의 실수라는 의견이 이어졌고, GrapheneOS 측은 CVE-2026-58882가 지정됐다고 보충했습니다.
- 호주에서 통신 서비스가 막힐 수 있다는 대목은 3G 종료용 규정을 과장했다는 반론과 구글이 책임질 사안이라는 주장으로 갈렸습니다.
문제 자체는 심각해 보이는데, 호주와 000번 얘기에서 공격당한 기기가 차단될 수 있다는 대목은 전형적으로 LLM이 지나치게 깐깐하게 쓴 문단 같아요. 상식이 완전히 빠져 있고요.
제가 순진하거나 틀린 걸 수도 있지만, 호주 법은 3G 전용 휴대폰을 쓰는 사람들을 앞으로 나아가게 하려고 만든 거잖아요. 망이 종료되고 000번이 5G로 옮겨 가니까요(제가 알기로는요). 결국 통신사가 아직 구형 폰을 쓰는 고객에게 연락해서 새 폰으로 갈아타게 하라는 법이라고요. 몇 날 며칠 연속으로 그 DoS를 당한다고 해서 번호를 자동으로 차단하진 않을 것 같은데요.
호주에는 이동통신 서비스를 제공하는 회사가 따라야 하는 법이 있습니다. 이런 취약점을 고치지 않으면 그 법을 위반하게 됩니다. 통신사든 휴대폰 제조사든 중간 사업자든, 어떤 경우에도 긴급 서비스 접근을 제한하거나 제한을 알면서 방치해서는 안 됩니다. 이 경우 구글은 이 문제를 인정하길 거부하고 있으니 제한을 알면서 방치하는 것으로 볼 수 있고, ACMA(호주통신미디어청)가 구글에 조치를 하거나 수정하도록 강제할 수 있을 거라고 생각합니다.
맞게 의심하신 겁니다. 그 법은 4G 기기이면서도 3G망으로 000번에 전화를 거는 휴대폰의 IMEI 번호를 차단하는 것에 관한 법입니다.
000번이 어떻게 5G 전용으로 옮겨 갈 수 있죠?
옮겨 간 게 아닙니다. 3G망이 종료됐어요. 4G를 지원하면서도 000번 통화는 3G로 거는 구형 기기가 몇 종 있었고, 그래서 이런 기기는 접속을 막아야 했습니다.
구글은 이걸 "보안 문제가 아니다"라고 분명하게, 그것도 여러 번 분류했어요. 이상한 버그인 건 분명한데, 그래서 어떤 시나리오가 가능하다는 거죠?
제가 틀렸다면 바로잡아 주세요. 통신사 구성(carrier configuration) 메시지는 원래 통신사만 보낼 수 있잖아요. 데모 APK는 폰 자신에게 메시지를 보내는 건데, SMS를 보내려면 별도 확인이 필요하고요.
현실적으로 위험이 뭔가요?
저장소의 readme에는 그렇게 안 적혀 있습니다.
"발신 기기에 설치한 뒤, 대상 번호를 입력하거나(활성 SIM에서 자동 입력 가능) 발신 SIM을 고르고 SEND CRASH SMS를 누릅니다. 대상 기기에서 확인하세요..."
APK를 설치하고, 사용할 SIM을 고르고, 피해자의 안드로이드 폰 번호를 입력한 다음 보내기를 누르면 됩니다. 그러면 전화(telephony) 앱이 죽었다가 재시작돼요. 수신 확인이 없으니 통신사가 문자를 다시 보내고, 그러면 또 죽는 일이 반복됩니다.
이 공격을 푸는 "수정" 방법은 SIM 카드를 비안드로이드 폰에 꽂아 수신 메시지를 확인 처리해 주거나, 연결이 계속 끊기는 상태로 며칠을 기다리는 것뿐입니다.
어, 그런데 악성코드를 직접 설치해야 한다면 원격도 아니고 제로 클릭도 아니지 않나요?
아니면 제가 잘못 이해했고, 아무 전화번호나 입력해도 이 문제를 일으킬 수 있다는 건가요? 그렇다면 안드로이드 문제라기보다 통신사 문제로 들리는데요.
그 소프트웨어는 발신 기기에 설치하는 겁니다.
네, 피해자 전화번호면 됩니다. 버그는 안드로이드에 있어요. 통신사는 메시지를 전달할 뿐이고요.
이게 통신사 구성이라고 어디에 적혀 있나요? 페이지를 훑어보니 WAP과 PDU가 언급되는데, 제가 대충 본 바로는 PDU는 WAP 메시지를 인코딩하는 과정의 일부일 뿐인 것 같습니다. 그렇다면 결국 네트워크에 WAP 메시지를 보낼 수 있는 사람이면 누구든, 통신사가 이 잘못된 메시지를 걸러내거나 차단하기 시작하지 않는 한 통신사가 알아서 재전송해 준다는 얘기 아닌가요?
저는 구글에서 ISE로 일했는데, 업무 중 하나가 들어온 보안 취약점 제보를 검토하는 것이었습니다. 이 제보가 제 손에 들어왔다면 저는 분명히 심각한 보안 문제로 분류했을 겁니다. 그냥 DoS일 뿐이라고 할 수 있지만 심각한 DoS예요. 저는 2차 엔지니어링 검토를 맡았고요. 웹사이트의 타임라인을 보면 1차 분류 담당자가 기각한 것 같습니다. 이런 일은 가끔 있었습니다. 1차 분류 담당자가 기각하면 안 될 것을 기각하거나, 반대로 그럴 가치가 없는 걸 올리기도 했죠. 제 개인적인 의견으로는 구글의 업무 품질이 지난 10년간 다소 떨어졌습니다. 안타깝네요...
구글은 6월 15일에 수정 사항을 커밋했고, 7월 중순 보안 프리뷰 패치로 배포됐습니다. GrapheneOS도 7월에 보안 프리뷰 릴리스로 배포했습니다. 11월 보안 공지에 정식으로 포함될 예정이지만, AOSP에는 10월에 패치가 올라갔습니다.
https://android.googlesource.com/platform/frameworks/opt/telephony/+/735d9672603fa206c4b43cb668c1aa273db70b97%5E%21/
CVE-2026-58882가 부여됐고, 2026년 11월 안드로이드 보안 공지에서 심각도는 Critical입니다. 저희는 2026072901 릴리스부터 이 패치를 보안 프리뷰 릴리스에 포함된 패치로 목록에 올려 뒀고, 릴리스 노트에서 확인하실 수 있습니다.
https://grapheneos.org/releases#2026072900
구글이 이 제보를 잘못 처리했습니다. 내부에서 의사소통에 문제가 있어서 제보를 부적절하게 다뤘을 가능성이 큽니다. 이미 내부에 등록된 이슈여서 WONTFIX가 아니라 중복으로 닫으려 했을 수도 있습니다. 애초에 닫은 것 자체가 실수였을 수도 있고요.
안드로이드는 분류(triage)를 외주로 돌리는 것 같아요. "안드로이드 팀에 전달하겠다" 같은 메시지가 오거든요. 의사소통 문제였던 것 같습니다. Will Not Fix로 처리해 놓고, 다음 릴리스에서 상위 호출 경로에 try/catch를 추가하는 식으로 버그를 "고쳤는데", 제가 제보하기 전에는 이걸 놓쳤어요.
이 제보를 이미 무시한 티켓의 중복으로 처리하기도 했고요.
제가 겪어 본 팀 중에는 크롬 팀이 소통하기 가장 쉬웠습니다. 개발자들이 실제로 답을 해 줬어요.
페이지는 이 내용을 반영해 고쳤습니다.
이 이슈에는 CVE-2026-58882가 부여됐고 심각도는 Critical이며 2026년 11월 보안 패치 수준에 포함됩니다. OEM은 2026년 7월에 패치를 받았고 그때부터 배포가 허용됐습니다. 지금 안드로이드의 패치 체계는 이렇게 돌아갑니다. GrapheneOS는 보안 프리뷰 패치에 접근할 수 있어서 2026년 7월에 사용자들에게 패치를 적용했습니다.
안드로이드의 공개 이슈 트래커는 진짜 이슈 트래커가 아닙니다. 거기에 보고된 내용에 대해 내부 이슈를 따로 만들어요. 그래서 논의가 거기서 이뤄지지 않습니다. 보안 버그 제보는 주로 포상금 요청으로 취급되고, 포상금 수령과 관련된 것 말고는 소통이 거의 없습니다. 다른 사람이 먼저 제보했다면 닫히고 추가 정보는 제공되지 않아요. 외부인이 처음 제보한 경우에도 어느 안드로이드 보안 공지에 포함됐는지 결국 알려주는 것 말고는 업데이트를 거의 받지 못하는데, 그마저도 OEM에 공개되어 패치가 허용된 지 몇 달 뒤입니다.
고생하셨네요! 얼마나 답답하셨을까요.
심각한 의사소통 문제가 있었다고 보는 쪽이 더 그럴듯합니다. 관련 수정 사항을 구글이 6월 15일에 커밋했고 CVE-2026-58882가 부여된 것으로 보입니다 [0]. GrapheneOS [1]는 일찍이 7월에 보안 프리뷰 채널로 수정을 배포할 수 있었고, 그 외에는 곧 나올 11월 보안 공지에 포함됩니다.
[0] https://android.googlesource.com/platform/frameworks/opt/telephony/+/735d9672603fa206c4b43cb668c1aa273db70b97%5E%21/
[1] https://x.com/GrapheneOS/status/2115848460578762757
https://android.googlesource.com/platform/frameworks/opt/telephony/+/android-4.4.2_r1.0.1%5E%21/
:grimace:
그게 LLM의 문제예요. 어떨 땐 지시를 너무 정확하게 따르고, 어떨 땐
stof를 쓰지 않고 느리고 버그 많은 IEEE-754 파서를 슬쩍 끼워 넣죠.페이지에 기기를 복구하려면 adb 명령이 필요하다고 나오는데, 정확히 어떤 adb 명령인지는 찾을 수 없습니다.
전반적으로 이렇게 멋진 웹페이지에 전용 주소까지 만들어 놓고, 정작 영향받은 기기를 #1 식별하는 방법과 #2 복구하는 방법은 설명이 없어서 좀 답답합니다.
전체 초기화 대신 com.android.phone의 저장소만 지우면 안 되나요?
복구하려고 telephony.db를 지웠는데, 2분 뒤에 통신사가 메시지를 다시 보냈어요...
유일한 해결책은 SIM/eSIM을 비안드로이드 기기에 넣는 겁니다.
아니면 4일을 기다리면 됩니다. SMS 전달의 일반적인 네트워크 타임아웃이 4일이거든요.
추측일 뿐인데, 메시지 수신 확인이 안 되니까 통신사가 재전송하는 게 원인일지도 모르겠네요?
네, 타당한 추측이에요. 제가 인용을 더 길게 했어야 했네요.
페이지에는 이 부분은 SIM을 비안드로이드 기기에 넣어서 대기 중인 메시지를 받고 네트워크에 수신 확인을 보내면 해결된다고 나와 있습니다.
그다음에 기기를 복구하는 방법은 "adb 명령"과 "초기화"라고만 막연하게 언급돼 있고, 기기에서 실제로 무엇을 해야 하는지는 설명을 찾을 수 없습니다.
구체적으로 궁금한 건 이겁니다. 이 문제로 손상되는 메시지 데이터베이스는 com.android.phone이 소유하고 (그 일부로 저장되어) 있는 건가요?
오페라 극장에 이게 필요해요. 관객 폰마다 메시지를 몇 통씩 보내 두면, 벨소리 하나 없이 공연을 즐길 수 있잖아요.
소리 나는 휴대폰을 가진 사람을 뒷자리로 쫓아내는 게 더 쉽지 않나요?
아뇨, 다른 사람과 대화하는 시대는 끝났어요. 사람 피드백이 전혀 없는 기술적 해법이 아니면 VC 투자받은 스타트업을 세울 수 있는 것도 아니니까, 당연히 현실 세계의 해법도 아니죠.
아니면 건물 어딘가에 불법 휴대폰 재머를 숨겨 두는 방법도 있죠.