Android 16 NAT-T 유지 패킷이 Always-on VPN 잠금 밖으로 UDP/4500 전송
- 일반 앱이 UdpEncapsulationSocket과 createSocketKeepalive 공개 API로 NAT-T 유지 패킷을 요청하면, Always-on VPN과 'VPN 없이는 연결 차단'을 켠 Pixel 8 Pro에서도 물리 AP로 고정 형식 UDP/4500 패킷이 최저 10초 간격으로 전송됨
- 프레임워크의 startNattKeepaliveWithFd는 전달받은 fd와 IpSec 리소스의 현재 소유 관계를 검증하지 않고, Wi-Fi 오프로드에 넘기기 전 원 호출자 UID의 VPN 잠금 정책도 적용하지 않음
- Samsung SM-F966B에서는 물리 IPv4 기본 게이트웨이를 향한 Wi-Fi 활성 슬롯이 24시간 32분 유지됐고, Nothing A059에서도 같은 공개 경로와 활성 콜백을 확인했으나 Nothing 기기는 독립 패킷 캡처와 지속 시간 측정을 하지 않음
- 보고서는 Android 12+ 공통 프레임워크 경로와 7개 WLAN 계열의 출하량 추정치를 바탕으로 Android 파생 기기 출하량의 91.24%가 노출 범위에 든다고 추정하며, F-Droid·IzzyOnDroid의 Git 원본 4,679개에서는 Android IPsec·IKE·NAT-T API 사용을 찾지 못함
Hacker News opinions
이 건은 공개 이슈가 아니고, 지금 나온 정보만 보면 Google이 움직일 가능성은 낮아 보임. GrapheneOS는 이미 알고 있고 수정 작업 중이라더라.
제보를 받고도 조치 없이 닫았다면, 유입 경위와 무관하게 지금은 누출을 남겨두기로 선택한 셈 아닌가.
GrapheneOS도 이메일 제보에 답하지 않았다고 해서 악의를 단정하진 않잖아. Google도 답이 없었다는 이유만으로 고의라고 보기엔 근거가 더 필요함.
보안 취약점 범위 밖이면 외부 보안 티켓은 닫히는 경우가 있음. 내부 이슈로는 추적할 수 있고, VPN 누출은 보통 보안 이슈로 분류되지 않아 우선순위와 구버전 백포트가 낮다는 설명임.
임시방편으로 이 종류의 오프로드 기능이 없는 USB-C WLAN 어댑터를 쓰면 될 듯함. 다만 셀룰러에서는 소용없겠지.
공개된 PoC는 Wi-Fi에서만 동작함. 셀룰러까지 새는지 여부는 이 자료로 확인된 게 아님.
그렇다면 VPN을 강제하는 공유기에만 Wi-Fi로 붙고 모바일 데이터는 쓰지 않는 편이 낫나 싶음. iOS에도 비슷한 누출이 있는지 궁금함.
'조치 없이 닫힘'이 제일 문제로 보임. 알고도 그대로 두면 더는 버그가 아니라 감수하는 동작 아닌가.
Google은 VPN 누출을 유효한 버그로 보되 보안 버그로는 분류하지 않는다는 설명이 있음. 보상 프로그램 범위 밖이면 외부 티켓은 닫히고, 그 자체가 수정 계획이 없다는 뜻은 아님.
GrapheneOS도 영향받고 있고 7월 29일 전부터 인지했지만 ETA는 없다고 함. 이슈에는 2주 동안 큰 업데이트가 없었는데, 그 사이 Messages 재작성은 알파로 나왔더라.
Android는 Always-on VPN과 트래픽 필터링을 쓰려면 PIN 설정을 강제하는 게 불편함. nft 접근권도 안 주니까 더 답답함.
PIN을 요구하는 건 몰래 스파이웨어를 설치하기 어렵게 만드는 장치이기도 함. VPN 경고나 아이콘은 숨길 여지가 있어도 갑자기 생긴 잠금화면 코드는 숨기기 힘들지.
FortiClient와 SmartVPN의 누적 Play 설치가 4,134,648건인데, API를 고치지 않고 없애자는 논리는 이상함. Google도 VPN 쪽 문제를 고칠 계획을 언급했다면 API 제거보다 그쪽을 고쳐야 함.
Network.bindSocket은 VPN 앱이 통제하는 SO_BINDTODEVICE 래퍼인데, Linux 5.7부터 비권한 사용자도 직접 setsockopt(SO_BINDTODEVICE)를 호출할 수 있음. Termux에서 curl --interface [ifname] ifconfig.co 정도로 VPN 또는 비VPN 인터페이스를 고르는 문제도 아직 Android와 GrapheneOS에 남아 있음.