WAP Push 문자 한 통에 안드로이드 통화 먹통, 구글은 '수정 안 함'
- WAP Push 헤더 길이를 uintvar로 읽어 long에서 int로 범위 검사 없이 캐스팅한 탓에 5바이트 88 80 80 80 00이 -2147483648로 해석되고, new byte[-2147483648]이 NegativeArraySizeException을 던져 com.android.phone 프로세스가 죽음
- 사용자 조작이 전혀 없고 알림도 남지 않아 발신번호조차 보이지 않으며, 진행 중인 통화가 DisconnectCause CS_DEATH로 끊기고 긴급통화도 여기 포함됨. 메시지 한 통당 1-2초 통신 불가가 생기고 20통쯤이면 기기를 사실상 쓸 수 없게 됨
- 페이로드를 30통 안팎 연속 전송하면 텔레포니 프로바이더의 SMS 저장소 쓰기와 경쟁 상태가 생겨 SQLite DB가 손상되고, 이후엔 새 메시지 없이도 부팅할 때마다 크래시함. 공장 초기화는 임시방편이라 SIM을 아이폰 같은 비안드로이드 기기로 옮겨 재전송을 끊고 ADB로 DB를 지워야 복구됨
- 구글은 2026년 5월 5일 접수된 VRP 신고를 Non-Security로 분류해 Won't Fix로 닫았고 CVE도 나오지 않음. 90일 뒤인 10월 29일 공개됐고 Pixel 9(2026년 4월 펌웨어)와 갤럭시/A 시리즈에서 100% 재현됐음
- 작성자는 호주 ACMA의 긴급통화 규정을 근거로 000에 연결되지 않는 단말은 통신사가 서비스를 중단해야 한다고 주장함. 구글이 보안 이슈로 인정하지 않는 동안 긴급통화가 막히는 걸 알고도 방치한 셈이라는 논리임
Hacker News opinions
새 취약점 나올 때마다 웹사이트 하나씩 새로 만드는 거 이제 좀 그만했으면 좋겠다. 진짜 피곤함.
그건 heartbleed 탓임. ChatGPT나 바이브코딩 나오기 한참 전부터 있던 관행이야. 사람들이 CVE-2014-0160이라고 하면 아무도 모르는데 heartbleed라고 하면 다 기억하잖아.
난 이런 프레젠테이션 좋은데. 안 좋으면 안 누르면 되는 거 아님?
CVE도 없고 won't fix인 상황이면 이렇게라도 해야지. 예전엔 그냥 익스플로잇 던져놓고 혼란 터지면 고치는 식이었음.
예전에 tel: 링크 누르면 삼성폰 데이터가 다 날아가던 거 기억남. 그게 어떻게 가능했는지 링크 좀.
이걸 어떻게 won't fix로 때리지? 이해가 안 감.
구글이 AI 슬롭에 파묻혀서 신고를 서드파티 AI로 걸러내다 진짜 버그까지 같이 새는 것 같음.
'if'가 핵심임. LLM은 항상 역사상 최악의 버그를 찾았다고 환각하니까. Claude가 만든 페이지를 왜 그대로 믿어?
WAP push가 뭔지 궁금해서 들어갔는데 Claude 말투만 잔뜩임. 'Zero-click. The victim does nothing.' 이런 문장이나 의미 없는 표만 나옴. 중요한 내용이면 직접 써서 올려야 하는 거 아님?
LLM은 문장만 다듬었고 크레딧은 상관없음. 메시지가 조용히, 발신번호도 없이 오고 잠금이나 데이터 연결과 무관하게 터진다는 게 요점임. 나는 이게 고쳐지는 게 중요함.
SMS를 대체 어떻게 보내냐. 통신망이 이상한 페이로드를 받아주기나 하냐?
사이트에서 APK를 줌. SMS가 전부 사용자한테 보이는 텍스트는 아니야. SS7은 연결된 망을 무조건 신뢰하는 구조라 예전에 보이스메일 알림을 위조해서 지울 수도 없는 알림을 띄운 적도 있음.
루팅폰으로 silent SMS 보내본 적 있는데 배달 보고서가 와서 상대 폰이 켜져 있는지 알 수 있었음. 알리에서 $50짜리 4G LTE 모뎀 보드만 있어도 API 제약은 다 우회 가능함.
구글 이슈 트래커 링크는 접근 거부 뜨던데.
보안 이슈는 원래 공개 안 됨. 나도 VRP로 신고했는데 중복으로 묶이고 원본은 볼 수 없었음.
호주 000 얘기는 LLM이 과하게 쓴 문단 같음. 3G 종료 때문에 만든 법인데 DoS 몇 시간 걸린다고 번호를 차단하진 않을 듯.
통신사가 긴급통화를 막는 걸 알면서 방치하는 건 그 법 위반임. 구글이 이걸 보안 이슈로 인정하지 않는 동안 ACMA가 개입할 근거는 충분해 보임.