Android가 기기 내 ADB를 곧 제한할 수 있음

• Google의 공식 발표가 아닌 진행 중인 IssueTracker 기능 요청에서 ADB 핵심 유지보수 담당자가 악용 방지를 위해 로컬 연결을 제한하고 wlan0에만 바인딩하는 방안을 거론함
• wlan0만 허용하면 루프백 주소 127.0.0.1을 이용하는 기기 내 ADB는 물론 VPN·Ethernet 기반 ADB와 여러 개발 환경까지 작동하지 않을 수 있음
• 논의는 Wireless ADB 인증을 완전히 우회한 CVE-2026-0073에서 시작됐으며, 원래 요청은 ADBD의 수신 인터페이스를 선택해 모든 네트워크에 노출되지 않도록 하자는 것임
• 일반적인 악성 앱은 ADBD를 직접 시작하거나 Wireless ADB 페어링·TCP/IP 승인을 단독으로 마칠 수 없어, 사용자의 수동 조작 없이는 ADB 권한을 얻기 어려움
• 루프백 연결을 영구 차단하면 Shizuku와 libadb-android 기반 도구가 영향을 받으므로, 기본 차단을 재부팅 후에도 해제할 수 있는 사용자 선택 설정이 필요함

---

공식 발표가 아닌 초기 논의

• 이번 사안은 Google의 확정된 정책이나 공식 발표가 아니라, 진행 중인 IssueTracker 기능 요청과 ADB 핵심 유지보수 담당자의 댓글을 근거로 함
• 담당자는 앱이 ADBD의 로컬 소켓을 사용해 권한을 높인 사례를 들어, ADBD를 Wi-Fi 인터페이스인 wlan0에만 바인딩하는 방안을 거론함
• 공개 논의에서는 단순 항의나 모욕, 동일한 사용 사례의 반복을 피해야 함
  • 고유한 사용 사례가 있다면 작업 흐름과 관련 링크, 기술적 절충안을 포함해 구체적으로 의견을 남길 수 있음
  • 같은 사례가 이미 등록됐다면 댓글을 반복하기보다 +1과 알림 기능을 이용하는 편이 권장됨
  • 저품질 댓글이 몰리면 이슈가 잠기거나 유용한 피드백과 공개 업데이트가 줄어들 수 있음

ADB의 세 가지 연결 방식

• ADB는 Android 기기를 시험하고 관리하는 개발자·고급 사용자에게 높은 권한의 명령 접근을 제공하는 프로토콜임
• 주요 연결 방식은 세 가지로 나뉨
  • USB: 별도 컴퓨터에서 USB 케이블로 기기에 직접 연결하는 원래 방식임
  • ADB TCP/IP: 일반적으로 5555 포트를 사용하며 트래픽이 평문으로 전달되고 YES/NO 승인 창으로 인증함. 기존 ADB 연결이 있어야 활성화할 수 있음
  • Wireless Debugging: Android 11에서 도입됐으며 코드나 QR 코드로 컴퓨터를 페어링한 뒤 인증·암호화된 연결을 구성함. 활성화에 기존 ADB 연결이 필요하지 않음

기기 내 ADB가 만든 생태계

• 일반적인 ADB는 Android 기기의 ADBD와 별도 개발 컴퓨터의 ADB 클라이언트를 연결하지만, 컴퓨터 없이 Android 기기에서 직접 작업하는 개발자도 있음
• 기기 내 ADB(On-Device ADB) 는 공식 용어가 아니며, Termux 같은 터미널 에뮬레이터에서 ADB 클라이언트를 실행해 같은 기기의 ADBD에 연결하는 방식을 가리킴
  • ADB TCP/IP 또는 Wireless Debugging을 사용함
  • 클라이언트와 서버가 같은 기기에 있으므로 루프백 주소 127.0.0.1 을 통함
• 이 방식은 libadb-android, Shizuku 등 개발자·고급 사용자용 오픈소스 프로젝트의 기반이 됨
• ShizuCallRecorder는 장애로 인한 일상적 어려움을 줄이기 위해 만들어진 Shizuku 기반 앱임
  • 한 사용자는 사망한 가족의 음성사서함을 보존하는 데 이 앱을 사용함
  • Android 통화 녹음은 사용자 요청이 많았고 Android 11에서 공식 기능이 추진됐다 취소됐으며, 현재는 폐쇄형이거나 사생활 침해 가능성이 있는 우회 앱도 존재함
  • 일부 OEM은 법적으로 필요하지 않은 지역에서도 통화 녹음 안내 음성을 강제함

인터페이스 선택 요청과 wlan0 제한

• 새 기능 요청의 본래 목적은 ADBD가 수신할 네트워크 인터페이스를 개발자가 선택할 수 있게 하는 것임
• 배경에는 Wireless ADB 인증 절차를 완전히 우회할 수 있었던 CVE-2026-0073이 있음
• 현재 ADBD는 휴대전화가 연결된 모든 네트워크에서 접근할 수 있어, 인터페이스 선택 기능 자체는 노출 범위를 줄일 수 있음
• 그러나 wlan0만 허용하면 다음 구성이 깨질 수 있음
  • 루프백을 사용하는 기기 내 ADB
  • VPN을 통한 ADB
  • Ethernet을 통한 ADB
  • 그 밖의 특수한 개발 환경
• Android 개발자도 컴퓨터에 접근할 수 없을 때 기기 내 ADB를 사용한 사례가 있음

악성 앱이 넘어야 하는 제약

• 기기 내 ADB가 권한 상승에 사용될 수는 있지만, 일반적인 악성 앱은 스스로 연결을 성립시킬 수 없음

• 일반 Android 사용자

  • ADB가 비활성화돼 있으면 ADBD가 실행되지 않음
  • 악성 앱에는 ADB를 통해 수동 부여해야 하는 WRITE_SECURE_SETTINGS 권한도 없어 ADB 공격을 시도하기 어려움

• Android 11 이상에서 Wireless ADB를 사용하는 개발자

  • 사용자가 USB 디버깅과 Wireless ADB를 직접 활성화해야 ADBD가 네트워크 인터페이스에서 수신함
  • 앱이 연결하려면 사용자가 설정 화면에서 일회용 페어링 코드를 가져와 제공해야 하므로 앱만으로는 연결할 수 없음

• ADB TCP/IP를 사용하는 개발자

  • 사용자가 USB 디버깅을 켜고 USB ADB로 TCP/IP를 활성화한 뒤 케이블을 분리해야 함
  • 앱이 연결을 시작하면 화면에 승인 창이 나타나며, 사용자가 No를 선택하면 거부됨
  • 정상적인 인증 상태에서는 앱이 사용자 모르게 연결해 공격할 수 없음

취약점 위험과 차단 범위

• 정상적인 상황에서는 악성 앱이 ADBD를 직접 시작할 수 없어, 개발자가 기기에서 ADB를 사용 중일 때만 연결 가능성이 생김
• CVE-2026-0073처럼 인증을 우회하는 취약점이 있다면 Wireless ADB와 TCP/IP 환경에서 악용될 수 있음
  • 그래도 사용자가 먼저 USB 디버깅을 수동 활성화해야 함
  • TCP/IP 방식은 사용자가 ADB TCP/IP까지 직접 켜야 함
• 루프백 연결을 기본적으로 막는 조치와 사용자가 해제할 수 없도록 영구 차단하는 조치는 구분해야 함
• 기기 관리자 지정이나 접근성 권한도 사용자의 조작으로 악성 앱에 부여될 수 있지만, 그 가능성만으로 기능 자체를 없애지는 않음

사용자 선택권을 남기는 절충안

• 루프백 차단은 사용자가 명시적으로 해제할 수 있는 지속 설정이어야 함
  • 재부팅 후에도 유지돼야 Shizuku 같은 도구를 실용적으로 사용할 수 있음
  • 가능하면 제3자 앱이 설정 상태를 읽을 수 없어야 은행 앱이나 게임의 탐지를 피하려고 반복해서 설정할 필요가 없음
  • 앱에 WRITE_SECURE_SETTINGS를 수동 부여하면 일부 제약을 우회할 수 있음
• 사용자가 보안 기능을 끄고 기기 내 디버깅을 허용하는 동시에, 향후 취약점에 노출될 위험도 감수하는 구조가 적절함
• 기기 내 ADB를 영구 차단하면 다음과 같은 틈새 오픈소스 생태계가 영향을 받음
  • App Manager
  • libadb-android
  • Canta
  • aShell
  • ShizuWall
  • ShizuCallRecorder
  • Shizuku

[unsure4000]

eww...

[GN⁺]

Hacker News 의견들

• 보안 개선에는 대체로 찬성하지만 여기서는 실익이 거의 없어 보임. 이 공격이 성립하려면 사용자가 개발자 설정과 원격 ADB를 모두 켜야 하므로 99.9%에게는 현실적인 공격 경로가 아니며, 나머지 0.1%는 대개 자신이 무엇을 하는지 알고 있음
  특정 인터페이스나 IP로 접근을 제한하는 변경은 좋지만 개발자가 localhost로 제한할 수 있게 하면 됨. Shizuku와 Canta 등을 부수적인 피해처럼 위장해 차단하려는 느낌이 강함

  • 이제 소프트웨어에서 보안은 재앙에 가까움. 사소한 사이트마다 2단계 인증을 요구하고, 몇 시간마다 로그아웃시키며, 에이전트를 무제한 모드로 실행하려고 disable sandbox까지 입력해도 모바일에서는 작동하지 않음
    Firefox에서는 서명되지 않은 확장 기능을 아예 설치할 수 없어 Developer Edition이 필요하고, 사이트들은 패스키를 강요하며, S3 버킷 하나에도 수십 겹의 접근 제어·서비스 신원·IAM·OAuth가 붙음. 헤드리스 장치에서 작동하지 않는 OAuth, TOTP 대신 전용 앱을 요구하는 은행, VPN 차단, 아동 보호를 명분으로 한 실명 감시, 중국으로 정보가 넘어간다며 개방형 가중치 모델을 금지하려는 움직임도 이어짐
    보안이 편의성·사용성·프라이버시·개조 가능성·개방성보다 언제나 우선하는 절대 가치가 됐으며, IT 보안 업계는 이를 부끄러워해야 함
  • 개발자 설정과 원격 ADB만으로도 부족함. 일반 Android 빌드는 연결 시 클라이언트 키 승인을 사용자에게 다시 요청함
    이번 변경은 사용자 보안이 아니라 기업의 이해관계 보호를 위한 것으로 보임
  • iPhone 이후 보안 기능으로 포장된 변화 중 상당수는 실제로 기기 기능 제거였음
    초기에는 앱 스토어 없이 Safari만 쓰라고 했고, 암 치료 중에도 디자인이 아름답지 않은 의료 기기가 몸에 닿는 것을 꺼렸다는 Steve Jobs 특유의 편집증이 근원이었다고 봄. “완벽한” 기기에 “불결한” 것이 닿지 않게 하려던 태도를 사후에 보안이라는 언어로 정당화했음
    당시에는 악성 코드투성이 Windows 98 같은 상황을 피해야 한다고 했지만, 현대 운영체제는 이미 그 시절 Windows의 취약한 보안 수준을 훨씬 넘어섰음
  • Android 앱을 배포한 개발자인데도 화면이 깨졌을 당시 까다로운 원격 ADB 토글이 꺼져 있어 기기에 접근하지 못한 적이 있음. 개발자 설정과 원격 ADB가 동시에 켜진 경우는 실제 환경에서 공격 경로로 무시해도 될 만큼 드묾
  • “악의적 행위자는 정상적인 상황에서 ADB 연결을 얻을 수 없다”는 말은 악의적 행위자를 어떻게 정의하느냐에 달렸음
    Shizuku 기반의 루트 없는 프라이버시 도구를 막는 목적은 소유자가 아니라 정부의 보안을 위한 것임. EU Digital Identity Wallet 같은 신뢰 실행 환경 애플리케이션과 앞으로 아동 보호를 명분으로 요구될 기능들은 사용자가 기기를 조작하거나 승인되지 않은 소프트웨어를 설치할 수 없다는 전제에 크게 의존함. Intel SGX가 어떻게 흘러가고 있는지는 모두 알고 있음

• ADB 제한은 당연한 다음 단계임. 이 제안이 그대로 통과되지 않아도 Google은 정상적인 개인 컴퓨팅 작업조차 기기 내부나 USB·무선의 개발자 인터페이스에 의존하게 만들었음
  언젠가는 신원을 넘기고 연간 요금을 내거나, Android를 의미 있게 사용하는 데 심각한 제한을 받게 될 가능성이 큼. Google은 통제된 유통 경로 밖에서 Android 앱을 개발하는 것을 원하지 않으며, 정상적이고 합법적인 사이드로딩을 금지하는 변경에서 물러서지 않았을 때 이미 패배한 셈임
  통화 녹음 경고도 Google 책임. 제조사들이 더 나았던 자체 다이얼러 대신 Google 다이얼러를 채택하면서 법적 의무가 없는 지역에도 일괄 적용됨. 특히 안정적인 서드파티 앱을 통한 녹음을 하드웨어 수준에서 지원하지 않는 MediaTek SoC에서는 더 성가심
  결국 “내” 기기를 소유하지 못한다는 증거이며, 몇 년 뒤에는 승인된 감시 경로를 통해 Gemini가 통화를 듣고 요약해 줄지도 모름

  • 내 경우는 다름. GNU/Linux 스마트폰 Librem 5에서 보낸 글임
  • 자체 운영체제를 설치할 수 있다면 그 기기를 소유한 것임. Google은 이를 꾸준히 허용해 왔으므로, 막는 다른 제조사에 분노를 돌려야 함

• 정당한 용도를 위한 대체 수단도 함께 제공되는지 궁금함. 기능을 제거하면서 대안을 주지 않으면 개발자들은 더 취약하거나 때로는 규칙을 어기는 우회법으로 밀려나게 됨

• 이번 반응은 오해에서 비롯된 큰 과잉 대응으로 보임. 원격 ADB로 개발 중인 Android 프로젝트의 새 빌드를 설치하고 로그를 가져오며, 현재는 Tailscale VPN을 통해 접속하고 있음
  하지만 지금 방식은 연결하는 모든 공용 Wi-Fi에서 인증 전 취약점까지 노출될 수 있음. Tailscale 인터페이스로만 제한할 수 있다면 오히려 개선됨
  제안의 핵심은 원격 ADB 설정 시 모든 인터페이스가 아니라 바인딩할 인터페이스를 지정하는 것임. localhost가 거부된다는 내용은 없으며, wlan0에만 바인딩하자는 짧은 제안은 VPN보다 신뢰도가 낮아 명백히 잘못됐고 실제 구현 방향도 아닐 것임

• 스레드 도배로 Google 개발자가 이슈를 잠그고 피드백을 무시한다 해도 지금과 달라질 것은 없음. 비판 자체가 거슬리면 가치 있는 피드백도 잠글 수 있으니 자유롭게 찬성 의사를 표현하면 됨

  • 정책 비판과 Reddit 군중의 집단 공세는 구분해야 함
  • Google 개발자들이 중요한 사용례를 단순히 놓쳤거나 오해했으며 알려주기만 하면 재고할 것이라는 글의 전제는 솔직히 모욕적임
  • 이런 글이 HN이나 Reddit에 올라오는 순간 누군가의 생각을 바꿀 가능성은 사라지고 GitHub 이슈도 곧 도배될 가능성이 큼
    Google이 앱 개발자의 피드백을 가끔 받기는 하지만, 이런 편법에 의존하는 오픈소스 개발자보다 내부 팀의 판단을 더 중시하는 것은 당연함
    ADB 데몬이 앱에서 루프백 주소로 ADB 세션을 열어 통화 녹음을 가능하게 하도록 설계된 것은 분명 아님. https://xkcd.com/1172/가 다시 떠오름
    개발자가 변경을 싫어하는 것이 틀렸다는 뜻은 아님. Google도 다이얼러에 통화 녹음을 추가했으니 해당 기능 자체는 지지하지만, 그렇다고 ADB 팀이 보안 강화를 하지 말아야 하는 것도 아님

• Google이 사이드로딩 제한을 처음 발표했을 때 “그래도 ADB가 있다”고 했고, 이에 반대한 이들은 거센 비판을 받았음
  이제 ADB를 활성화하는 우회법까지 기다려야 하며, Android는 오래전부터 iOS보다 더 개방적이지 않았음. 이 흐름은 계속될 것임
  Google의 사고방식이라는 비기술적 문제이므로 기술적 해결책으로는 풀 수 없음

  • 하드웨어 원격 증명을 도입한 순간 Android는 이미 가망이 없어졌음
    자체 소프트웨어를 설치할 수 있어도 기기를 “변조”한 것으로 처리됨. 증명에 실패하면 신뢰받지 못해 통신·은행·스트리밍·게임 등 디지털 사회의 거의 모든 영역에서 배제되는 2등 시민이 됨
    이것이 Android의 미래이며, 일부 기업이 기적적으로 GrapheneOS의 증명 키를 신뢰하기 시작했기 때문에 GrapheneOS가 마지막 희망임. 그 희망마저 사라지면 차라리 iPhone을 사는 편이 나음
  • 이런 사고방식을 통제하는 줄은 Google 경영진과 이사회를 훨씬 넘어선 곳까지 이어져 있음. Carpenter의 고전 속 OBEY가 떠오름

• 당연히 벌어질 일이었음. 다음에는 24시간이라는 사이드로딩 제한이 무기한으로 바뀌어도 사람들이 놀랄 듯함

  • 그 전에 갈아탈 실질적인 대안이 생기느냐에 따라 무기한 제한으로 바뀔 가능성이 큼
    시장 전체를 장악할 필요는 없고, Google을 망설이게 하거나 법적으로 실행하기 어렵게 할 정도면 충분함. Chrome에 대한 Firefox의 이상적인 역할과 비슷함

• Android가 이 정도로 잠기는 것은 심각한 경고 신호임. Android를 좋게 만들었던 요소들을 하나씩 천천히 제거하고 있음

• 곧 웹사이트에도 같은 일이 생길까 걱정됨. Apple 기기에서 사이트를 열게 하려면 Apple에, Android 기기에서는 Google에 매달 요금을 내야 하는 식이 될 수 있음

  • 원격 증명을 요구하는 새로운 reCAPTCHA가 이미 그 방향임
    https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...
    아직 요금은 없지만 Google이 상당수 웹사이트에 대해 어떤 기기의 접속을 허용할지 결정할 수 있게 됨
  • 웹이 둘로 갈릴 수 있음. 상위 주요 사이트들이 비용을 지불하는 새로운 웹과, 제한 없는 브라우저가 설치된 개인용 PC를 소유해야만 접근 가능한 옛 웹으로 나뉠 것임
    옛 웹의 콘텐츠는 AI 기업이 대규모로 긁어 간 뒤 새로운 웹을 통해 대중에게 재생산할 가능성도 큼
  • Netflix 등 영상 스트리밍 서비스에서는 이미 비슷함. 직접 요금을 낼 필요는 없지만 오픈소스 브라우저를 사용할 수 없음

• 스마트폰용 Linux가 필요함. 은행 업무는 브라우저로 할 수 있다면 앱이 필요 없지만, 무선 통신 장치와 Sonos·Spotify 같은 주요 앱은 작동해야 함

  • 영국의 많은 은행은 이제 웹 포털도 오프라인 지점도 제공하지 않음
    은행·공공요금 같은 필수 서비스에는 정상적으로 작동하는 웹 환경을 의무화하는 법이 필요함. 그렇지 않으면 현재의 양강 구도가 더욱 고착됨
    나 역시 웹 서비스를 제공하는 업체를 선택해 더 적극적으로 지지해야 함
  • Android·LineageOS·GrapheneOS를 권하는 것은 적절하지 않고, Sailfish도 독점 구성요소가 많아 건너뛰는 편이 나음. 가장 좋은 선택은 postmarketOS이며 Mobian 등도 고려할 만하고, Ubuntu Touch와 UBports는 실망스러웠음
    postmarketOS 위키에서 호환 기기를 확인해 이미 가진 기기를 지원하는지 보고, 가능하면 지원 개선에 기여하면 됨. 아니라면 지원 상태가 좋은 중고 기기를 eBay에서 찾을 수 있음
    Librem 5와 PinePhone은 지원이 좋은 편이지만, OnePlus 6T 같은 구형 Android 기기가 가격 대비 성능은 더 나을 수 있음. 구매 전 주요 기능의 작동 여부를 확인해야 함
    인기 Android 앱은 Waydroid로 실행할 수 있음
  • 은행 웹사이트와 네이티브 앱의 기능 동등성을 요구해야 함. 내 은행은 원격 수표 입금을 앱에서만 지원하고 오래된 기기에서는 앱이 작동하지 않아 PayPal을 써야 함
  • 모든 스마트폰에 잠금 해제 가능한 부트로더가 필요함. 그러면 더 많은 운영체제가 등장할 수 있음
  • 요즘 은행들은 “보안”을 이유로 앱을 강제하며, 앱 없이는 업무 처리가 거의 불가능함
    대안인 SMS 인증도 안전하지 않아 사라지는 중인데, 보안상으로는 올바른 방향이지만 사용 가능한 다른 수단이 부족함