- In einer laufenden IssueTracker-Funktionsanfrage, nicht in einer offiziellen Ankündigung von Google, erwähnte der Hauptbetreuer von ADB als Maßnahme gegen Missbrauch, lokale Verbindungen einzuschränken und nur an
wlan0zu binden - Wenn nur
wlan0erlaubt ist, könnten nicht nur On-Device-ADB über die Loopback-Adresse127.0.0.1, sondern auch ADB über VPN oder Ethernet sowie verschiedene Entwicklungsumgebungen nicht mehr funktionieren - Die Diskussion begann mit CVE-2026-0073, das die Authentifizierung von Wireless ADB vollständig umging; die ursprüngliche Anfrage war, die Empfangsschnittstelle von ADBD auswählbar zu machen, damit es nicht in allen Netzwerken exponiert ist
- Normale Schad-Apps können ADBD weder direkt starten noch das Pairing für Wireless ADB oder die TCP/IP-Freigabe allein abschließen, daher ist es schwer, ohne manuelle Nutzeraktion ADB-Rechte zu erhalten
- Da eine dauerhafte Sperre von Loopback-Verbindungen Shizuku und Tools auf Basis von libadb-android betreffen würde, ist eine vom Nutzer wählbare Einstellung nötig, mit der sich die Standardsperre auch nach einem Neustart deaktivieren lässt
Frühe Diskussion, keine offizielle Ankündigung
- Bei dieser Angelegenheit handelt es sich weder um eine beschlossene Richtlinie noch um eine offizielle Ankündigung von Google, sondern um eine laufende IssueTracker-Funktionsanfrage und Kommentare des Hauptbetreuers von ADB
- Der Betreuer verwies auf Fälle, in denen Apps den lokalen Socket von ADBD zur Rechteausweitung nutzten, und erwähnte als mögliche Maßnahme, ADBD nur an die Wi‑Fi-Schnittstelle
wlan0zu binden - In der öffentlichen Diskussion sollte man bloße Proteste oder Beleidigungen sowie Wiederholungen desselben Anwendungsfalls vermeiden
- Wer einen eigenen Anwendungsfall hat, kann konkret Feedback hinterlassen, idealerweise mit Workflow, relevanten Links und technischen Kompromissvorschlägen
- Wenn derselbe Fall bereits eingetragen wurde, wird eher empfohlen, +1 und Benachrichtigungen zu nutzen, statt denselben Kommentar zu wiederholen
- Wenn viele Kommentare von geringer Qualität eingehen, kann das Issue gesperrt werden oder es gibt weniger nützliches Feedback und öffentliche Updates
Die drei Verbindungsarten von ADB
- ADB ist ein Protokoll, das Entwicklern und fortgeschrittenen Nutzern hohen Befehlszugriff zum Testen und Verwalten von Android-Geräten bietet
- Die wichtigsten Verbindungsarten lassen sich in drei Typen einteilen
- USB: die ursprüngliche Methode, bei der ein separates Computergerät per USB-Kabel direkt mit dem Gerät verbunden wird
- ADB TCP/IP: verwendet in der Regel Port
5555, überträgt den Datenverkehr im Klartext und authentifiziert mit einem YES/NO-Bestätigungsdialog. Es kann nur aktiviert werden, wenn bereits eine bestehende ADB-Verbindung vorhanden ist - Wireless Debugging: wurde mit Android 11 eingeführt und richtet nach dem Pairing eines Computers per Code oder QR-Code eine authentifizierte und verschlüsselte Verbindung ein. Zur Aktivierung ist keine bestehende ADB-Verbindung nötig
Das durch On-Device-ADB entstandene Ökosystem
- Normales ADB verbindet den ADB-Client auf einem separaten Entwicklungsrechner mit ADBD auf dem Android-Gerät, aber es gibt auch Entwickler, die direkt auf dem Android-Gerät ohne Computer arbeiten
- On-Device ADB ist kein offizieller Begriff, sondern bezeichnet die Methode, in einem Terminal-Emulator wie Termux einen ADB-Client auszuführen und ihn mit ADBD auf demselben Gerät zu verbinden
- Dabei wird ADB TCP/IP oder Wireless Debugging verwendet
- Da Client und Server auf demselben Gerät laufen, erfolgt die Verbindung über die Loopback-Adresse
127.0.0.1
- Diese Methode bildet die Grundlage für Open-Source-Projekte für Entwickler und fortgeschrittene Nutzer wie libadb-android und Shizuku
- ShizuCallRecorder ist eine auf Shizuku basierende App, die entwickelt wurde, um alltägliche Schwierigkeiten durch Behinderungen zu verringern
- Ein Nutzer verwendete die App, um die Voicemail eines verstorbenen Familienmitglieds zu bewahren
- Die Nachfrage nach Anrufaufzeichnung unter Android war hoch; für Android 11 war eine offizielle Funktion geplant, wurde aber wieder gestrichen, und derzeit existieren auch geschlossene oder potenziell datenschutzverletzende Umgehungs-Apps
- Manche OEMs erzwingen Ansagehinweise zur Anrufaufzeichnung auch in Regionen, in denen das rechtlich nicht erforderlich ist
Anfrage zur Schnittstellenauswahl und die Beschränkung auf wlan0
- Das eigentliche Ziel der neuen Funktionsanfrage ist, dass Entwickler die Netzwerkschnittstelle auswählen können, auf der ADBD Verbindungen entgegennimmt
- Hintergrund ist CVE-2026-0073, das die Authentifizierung von Wireless ADB vollständig umgehen konnte
- Derzeit ist ADBD über alle Netzwerke erreichbar, mit denen das Telefon verbunden ist; die Auswahl der Schnittstelle könnte die Exponierung daher grundsätzlich verringern
- Wenn jedoch nur
wlan0erlaubt ist, könnten folgende Konfigurationen nicht mehr funktionieren- On-Device-ADB über Loopback
- ADB über VPN
- ADB über Ethernet
- andere spezielle Entwicklungsumgebungen
- Auch Android-Entwickler haben On-Device-ADB verwendet, wenn sie keinen Zugriff auf einen Computer hatten
Hürden für Schad-Apps
- On-Device-ADB kann zwar zur Rechteausweitung genutzt werden, aber normale Schad-Apps können die Verbindung nicht selbstständig herstellen
-
Normale Android-Nutzer
- Wenn ADB deaktiviert ist, läuft ADBD nicht
- Schad-Apps fehlt außerdem die Berechtigung
WRITE_SECURE_SETTINGS, die manuell über ADB vergeben werden müsste, sodass ein Angriff über ADB schwer umzusetzen ist
-
Entwickler, die unter Android 11 oder neuer Wireless ADB nutzen
- Erst wenn der Nutzer USB-Debugging und Wireless ADB selbst aktiviert, nimmt ADBD auf Netzwerkschnittstellen Verbindungen an
- Damit eine App verbinden kann, muss der Nutzer in den Einstellungen einen einmaligen Pairing-Code abrufen und bereitstellen; die App allein kann die Verbindung daher nicht herstellen
-
Entwickler, die ADB TCP/IP verwenden
- Der Nutzer muss USB-Debugging aktivieren, TCP/IP über USB-ADB einschalten und danach das Kabel trennen
- Wenn eine App die Verbindung startet, erscheint ein Bestätigungsdialog; wählt der Nutzer No, wird die Verbindung abgelehnt
- Bei normaler Authentifizierung kann eine App nicht unbemerkt eine Verbindung herstellen und angreifen
Risiko durch Schwachstellen und Umfang der Sperre
- Unter normalen Umständen können Schad-Apps ADBD nicht direkt starten; eine Verbindungsmöglichkeit entsteht daher nur, wenn ein Entwickler ADB gerade auf dem Gerät nutzt
- Bei Schwachstellen, die die Authentifizierung umgehen, wie CVE-2026-0073, wäre ein Missbrauch in Umgebungen mit Wireless ADB und TCP/IP möglich
- Dennoch muss der Nutzer zuvor USB-Debugging manuell aktivieren
- Für die TCP/IP-Methode muss der Nutzer zusätzlich ADB TCP/IP selbst einschalten
- Es sollte zwischen einer standardmäßigen Sperre von Loopback-Verbindungen und einer dauerhaften Sperre unterschieden werden, die der Nutzer nicht aufheben kann
- Auch die Ernennung zum Geräteadministrator oder die Vergabe von Bedienungshilfen-Berechtigungen kann durch Nutzerinteraktion an Schad-Apps erfolgen, dennoch wird die Funktion nicht allein wegen dieser Möglichkeit abgeschafft
Ein Kompromiss, der Nutzerwahl lässt
- Eine Sperre von Loopback-Verbindungen sollte eine dauerhafte Einstellung sein, die der Nutzer ausdrücklich deaktivieren kann
- Sie sollte auch nach einem Neustart erhalten bleiben, damit Tools wie Shizuku praktisch nutzbar bleiben
- Wenn möglich, sollten Drittanbieter-Apps den Status der Einstellung nicht auslesen können, damit man sie nicht wiederholt ändern muss, nur um Erkennung durch Banking-Apps oder Spiele zu vermeiden
- Wenn einer App
WRITE_SECURE_SETTINGSmanuell erteilt wird, lassen sich manche Einschränkungen umgehen
- Es erscheint angemessen, dass Nutzer eine Sicherheitsfunktion deaktivieren und Debugging auf dem Gerät erlauben können, dabei aber auch das Risiko einer Exponierung gegenüber künftigen Schwachstellen in Kauf nehmen
- Eine dauerhafte Sperre von On-Device-ADB würde folgende Nischen-Ökosysteme im Open Source-Bereich betreffen
2 Kommentare
Igitt ...
Meinungen auf Hacker News
Ich bin grundsätzlich für Sicherheitsverbesserungen, aber hier scheint der praktische Nutzen sehr gering zu sein. Damit dieser Angriff funktioniert, müsste der Nutzer sowohl Entwickleroptionen als auch Remote-ADB aktivieren; für 99,9 % ist das also kein realistischer Angriffsweg, und die übrigen 0,1 % wissen meist, was sie tun.
Eine Änderung, die den Zugriff auf bestimmte Interfaces oder IPs beschränkt, ist sinnvoll, aber Entwickler sollten ihn einfach auf localhost begrenzen können. Es wirkt stark so, als wolle man Shizuku, Canta und Ähnliches blockieren und das als Kollateralschaden tarnen.
disable sandboxeingibt, um einen Agent im unbegrenzten Modus laufen zu lassen, funktioniert es auf Mobilgeräten nicht.In Firefox lassen sich unsignierte Erweiterungen gar nicht installieren, sodass man die Developer Edition braucht; Websites erzwingen Passkeys; selbst an einem einzelnen S3-Bucket hängen Dutzende Schichten aus Zugriffskontrolle, Service-Identitäten, IAM und OAuth. Dazu kommen OAuth, das auf Headless-Geräten nicht funktioniert, Banken, die statt TOTP eine eigene App verlangen, VPN-Blockaden, Klarnamenüberwachung unter dem Vorwand des Kinderschutzes und Bestrebungen, offene Weight-Modelle zu verbieten, weil angeblich Informationen nach China abfließen.
Sicherheit ist zu einem absoluten Wert geworden, der immer über Bequemlichkeit, Nutzbarkeit, Privatsphäre, Modifizierbarkeit und Offenheit steht, und die IT-Sicherheitsbranche sollte sich dafür schämen.
Diese Änderung wirkt nicht wie Nutzersicherheit, sondern wie der Schutz unternehmerischer Interessen.
Anfangs hieß es, man solle ohne App Store nur Safari verwenden, und ich denke, der Ursprung lag in Steve Jobs’ typischer Paranoia, der selbst während seiner Krebsbehandlung nicht wollte, dass ein medizinisches Gerät, das nicht schön gestaltet war, seinen Körper berührt. Die Haltung, nichts „Unreines“ an das „perfekte“ Gerät heranzulassen, wurde nachträglich mit Sicherheitsvokabular gerechtfertigt.
Damals hieß es, man müsse Zustände wie bei Windows 98 voller Malware vermeiden, aber moderne Betriebssysteme haben das schwache Sicherheitsniveau des damaligen Windows längst weit hinter sich gelassen.
Das Ziel, rootlose Datenschutz-Tools auf Basis von Shizuku zu blockieren, dient nicht der Sicherheit des Besitzers, sondern der Sicherheit von Regierungen. Trusted-Execution-Environment-Anwendungen wie die EU Digital Identity Wallet und Funktionen, die künftig unter dem Vorwand des Kinderschutzes verlangt werden, hängen stark von der Annahme ab, dass Nutzer ihr Gerät nicht manipulieren oder nicht autorisierte Software installieren können. Wir wissen alle, wohin sich Intel SGX entwickelt hat.
ADB-Beschränkungen sind der naheliegende nächste Schritt. Selbst wenn dieser Vorschlag nicht unverändert durchkommt, hat Google selbst normale Personal-Computing-Aufgaben davon abhängig gemacht, dass man interne Geräte- oder USB-/Wireless-Entwicklerschnittstellen nutzt.
Irgendwann wird man sehr wahrscheinlich seine Identität preisgeben und eine Jahresgebühr zahlen müssen oder bei der sinnvollen Nutzung von Android massiv eingeschränkt werden. Google will nicht, dass Android-Apps außerhalb kontrollierter Vertriebskanäle entwickelt werden, und die Niederlage war im Grunde schon besiegelt, als sie von Änderungen nicht abrückten, die normales und legales Sideloading verbieten.
Auch die Warnung bei Anrufaufzeichnungen geht auf Googles Konto. Als Hersteller statt ihrer besseren eigenen Dialer den Google-Dialer übernahmen, wurde sie pauschal auch in Regionen angewandt, in denen es keine rechtliche Pflicht dazu gibt. Besonders lästig ist das bei MediaTek-SoCs, die Aufzeichnungen über stabile Drittanbieter-Apps nicht auf Hardwareebene unterstützen.
Letztlich ist das ein Beleg dafür, dass man „sein“ Gerät nicht besitzt, und in ein paar Jahren hört Gemini vielleicht über einen freigegebenen Überwachungsweg bei Anrufen mit und fasst sie zusammen.
Ich frage mich, ob auch Alternativen für legitime Anwendungsfälle bereitgestellt werden. Wenn man Funktionen entfernt, ohne Ersatz anzubieten, werden Entwickler zu unsichereren oder manchmal regelwidrigen Workarounds gedrängt.
Diese Reaktion wirkt wie eine große Überreaktion aufgrund eines Missverständnisses. Ich installiere per Remote-ADB neue Builds eines Android-Projekts, an dem ich entwickle, und hole Logs ab; derzeit verbinde ich mich über ein Tailscale-VPN.
In der aktuellen Form kann das aber in jedem öffentlichen WLAN, mit dem ich mich verbinde, sogar vor der Authentifizierung Angriffsfläche bieten. Wenn man es auf das Tailscale-Interface beschränken könnte, wäre das eher eine Verbesserung.
Der Kern des Vorschlags ist, beim Einrichten von Remote-ADB nicht alle Interfaces zu verwenden, sondern das Interface anzugeben, an das gebunden werden soll. Es steht dort nicht, dass localhost abgelehnt wird; der kurze Vorschlag, nur an
wlan0zu binden, ist gegenüber einem VPN klar weniger vertrauenswürdig und offensichtlich falsch, und so wird die tatsächliche Implementierung wohl auch nicht aussehen.Selbst wenn Google-Entwickler wegen Thread-Spam das Issue sperren und Feedback ignorieren, wäre das nicht anders als jetzt. Wenn schon Kritik an sich stört, kann man auch wertvolles Feedback sperren; also kann man ruhig Zustimmung äußern.
Google nimmt zwar gelegentlich Feedback von App-Entwicklern an, aber natürlich gewichtet es die Einschätzung interner Teams stärker als die von Open-Source-Entwicklern, die sich auf solche Umwege verlassen.
Der ADB-Daemon wurde ganz sicher nicht dafür entworfen, dass Apps über die Loopback-Adresse eine ADB-Session öffnen, um Anrufaufzeichnungen zu ermöglichen. https://xkcd.com/1172/ kommt einem wieder in den Sinn.
Das heißt nicht, dass Entwickler falschliegen, wenn ihnen die Änderung missfällt. Google hat dem Dialer ebenfalls Anrufaufzeichnung hinzugefügt, unterstützt die Funktion an sich also, aber das bedeutet nicht, dass das ADB-Team keine Sicherheitsverschärfung vornehmen sollte.
Als Google die Einschränkungen fürs Sideloading erstmals ankündigte, hieß es: „Es gibt ja immer noch ADB“, und diejenigen, die widersprachen, wurden heftig kritisiert.
Jetzt muss man sogar auf einen Workaround warten, um ADB zu aktivieren; Android ist schon lange nicht mehr offener als iOS. Dieser Trend wird weitergehen.
Da es sich um ein nichttechnisches Problem in Googles Denkweise handelt, lässt es sich nicht mit einer technischen Lösung beheben.
Selbst wenn man eigene Software installieren kann, wird das Gerät als „manipuliert“ behandelt. Scheitert die Attestation, gilt man als nicht vertrauenswürdig und wird zum Bürger zweiter Klasse, der von fast allen Bereichen der digitalen Gesellschaft ausgeschlossen ist – Kommunikation, Banking, Streaming, Gaming usw.
Das ist die Zukunft von Android, und GrapheneOS ist die letzte Hoffnung, weil einige Unternehmen wie durch ein Wunder begonnen haben, den Attestation-Keys von GrapheneOS zu vertrauen. Wenn selbst diese Hoffnung verschwindet, ist es besser, gleich ein iPhone zu kaufen.
Das war natürlich zu erwarten. Als Nächstes werden die Leute wohl überrascht sein, wenn die 24-Stunden-Beschränkung fürs Sideloading auf unbestimmte Zeit verlängert wird.
Sie muss nicht den ganzen Markt übernehmen; es reicht, wenn sie Google zögern lässt oder die Umsetzung rechtlich schwierig macht. Ähnlich der idealen Rolle von Firefox gegenüber Chrome.
Dass Android in diesem Ausmaß abgeschottet wird, ist ein ernstes Warnsignal. Die Dinge, die Android gut gemacht haben, werden nach und nach entfernt.
Ich fürchte, dass bald dasselbe mit Websites passiert. Um eine Website auf Apple-Geräten öffnen zu lassen, muss man dann möglicherweise Apple zahlen, auf Android-Geräten Google – jeden Monat.
https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...
Noch gibt es keine Gebühr, aber Google kann dadurch für eine beträchtliche Zahl von Websites entscheiden, welche Geräte Zugriff erhalten.
Es ist gut möglich, dass Inhalte aus dem alten Web von KI-Unternehmen in großem Stil abgegriffen und dann über das neue Web der Öffentlichkeit wieder ausgespielt werden.
Wir brauchen Linux für Smartphones. Wenn Banking im Browser möglich ist, braucht man keine App; aber Mobilfunk und wichtige Apps wie Sonos oder Spotify müssen funktionieren.
Für essenzielle Dienste wie Banken und Versorger braucht es Gesetze, die eine ordnungsgemäß funktionierende Web-Umgebung vorschreiben. Andernfalls verfestigt sich das heutige Duopol nur weiter.
Auch ich sollte Anbieter, die Webdienste bereitstellen, bewusster wählen und stärker unterstützen.
Im Wiki von postmarketOS kann man kompatible Geräte prüfen und sehen, ob ein bereits vorhandenes Gerät unterstützt wird; wenn möglich, kann man zur Verbesserung des Supports beitragen. Falls nicht, findet man bei eBay gebrauchte Geräte mit gutem Supportstatus.
Librem 5 und PinePhone sind recht gut unterstützt, aber ältere Android-Geräte wie das OnePlus 6T können ein besseres Preis-Leistungs-Verhältnis bieten. Vor dem Kauf sollte man prüfen, ob die wichtigsten Funktionen funktionieren.
Beliebte Android-Apps lassen sich mit Waydroid ausführen.
Die Alternative SMS-Authentifizierung ist ebenfalls unsicher und verschwindet allmählich, was aus Sicherheitssicht richtig ist, aber es fehlen brauchbare andere Optionen.