Google wird Android-Apps erlauben, ein Dutzend well-known Ports (kleiner als 1024) zu nutzen. Das \u00f6ffnet neue Einsatzm\u00f6glichkeiten f\u00fcr popul\u00e4re Android-Ger\u00e4te, insbesondere im lokalen Netzwerk. Konkret sollen mit dem n\u00e4chsten Update des Google Play Systems Android-Apps bei Bedarf Zugriff auf diese neun TCP-Ports erhalten: 20 und 21 (typischerweise f\u00fcr FTP genutzt), 22 (SSH\/SFTP), 23 (Telnet), 80 (HTTP), 443 (HTTPS), 445 (SMB), sowie die beiden regelm\u00e4\u00dfig f\u00fcr vernetzte Drucker eingesetzten Ports 515 (LPD) und 631 (IPP).<\/p>\n
Weiterlesen nach der Anzeige<\/p>\n
Hinzu kommen drei UDP-Ports: 319\/320 (typischerweise f\u00fcr Zeitgeber-Synchronisierung mittels PTP) und 443 (f\u00fcr das QUIC-basierte WWW-Protokoll HTTP\/3). Das geht aus einer am Wochenende ver\u00f6ffentlichten Mitteilung im \u00f6ffentlichen Bugtracker Androids hervor. Kein Gl\u00fcck haben beispielsweise Nutzer von TFTP (UDP-Port\u00a069) oder Doom-Fans (klassisch Port\u00a0666).<\/p>\n
Bislang sperrt Google auf seinen Android-Versionen grunds\u00e4tzlich Ports kleiner 1024. Nur wenn solche Android-Implementierungen gerootet sind, kann der Administrator die sogenannten well-known Ports zug\u00e4nglich machen. Das schw\u00e4cht unter Umst\u00e4nden bestimmte IT-Sicherheitsma\u00dfnahmen.<\/p>\n
Ein bisschen Glasnost<\/p>\n
Daher regen Entwickler im Android Bugtracker seit vielen Jahren an, die Einschr\u00e4nkung fallen zu lassen. Doch Google hat das mehrfach als \u201eabsichtliches Verhalten\u201d eingestuft und das Gesuch abgelehnt (\u201eWon’t Fix\u201d). Im Oktober 2021 \u00fcberraschte ein Googler mit der \u201eErkl\u00e4rung\u201d, dass \u201eraw sockets konstante Quelle f\u00fcr kernel exploits\u201d seien, weshalb die Verbesserung nicht infrage komme. Dabei hatte niemand nach raw sockets (OSI-Layer\u00a02 oder 3) gefragt, sondern lediglich nach Zugang f\u00fcr unprivilegierte Apps auf Layer\u00a04.<\/p>\n
Auch den zumindest dritten Anlauf vor gut vier Jahren hat Google mit \u201eWon’t Fix\u201d abgeschmettert. Doch vorige Woche entdeckte ein wom\u00f6glich deutscher Entwickler, dass Anwendungen in der Developer Preview auf Android 17 Zugriff auf die UDP-Ports 319 und 320 ergattert<\/a> haben.<\/p>\n Daraufhin rang Google sich zu einer teilweisen \u00d6ffnung durch<\/a>, auch f\u00fcr altere Androids. Die grunds\u00e4tzliche Herangehensweise, well-known Ports zu sperren, bleibt aufrecht. So viel Orthodoxie muss offenbar sein. Immerhin wird die Nutzung der zw\u00f6lf obgenannten Ports erm\u00f6glicht.<\/p>\n Technisch gesehen setzt Google die neue Port-Whitelist mittels eBPF (extended Berkley Packet Filter)<\/a> um. Das erfolgt in jenem APEX-Modul, das in Android Mainline f\u00fcr Datenverbindungen samt Tethering zust\u00e4ndig ist. Solche Module k\u00f6nnen durch Google Play Updates erneuert werden und bed\u00fcrfen keines Updates des gesamten Betriebssystems. Der Konzern k\u00f6nnte Zukunft also relativ einfach weitere well-known Ports zur Verf\u00fcgung stellen, wenn er denn m\u00f6chte.<\/p>\n Weiterlesen nach der Anzeige<\/p>\n Voraussetzungen und Vergleich<\/p>\n Voraussetzung f\u00fcr den neuen Portzugriff sind sowohl mindestens Android\u00a013 (API-Version\u00a033 und h\u00f6her) als auch mindestens Linux-Kernel\u00a05.15. Damit sind Anwender erst mit Systemen, die neu mit Googles Android 14<\/a> ausgeliefert wurden, auf der sicheren Seiten. Mobiltelefone, die mit Googles Android\u00a013 neu ausgeliefert wurden, durften Kernel\u00a05.10 oder 5.15 nutzen, sind also nicht alle mit dabei. Ger\u00e4te, die mit \u00e4lteren Android-Versionen auf den Markt gekommen und sp\u00e4ter auf j\u00fcngere Versionen des Betriebssystems upgegradet worden sind, k\u00f6nnen sogar mit noch \u00e4lteren Kernel-Versionen laufen.<\/p>\n Bei den Android-Varianten Android Auto, TV und Wear k\u00f6nnte die Verbesserung l\u00e4nger auf sich warten lassen. Das gilt auch f\u00fcr Android Go; das ist eine f\u00fcr weniger leistungsstarke Handys und Mobilfunknetze optimierte<\/a> Android-Variante.<\/p>\n Die Einschr\u00e4nkung der niedrigen Ports ist auch bei anderen Linux-Systemen \u00fcblich. Allerdings ist es dort Administratoren in der Regel ein Leichtes, bei Bedarf Anwendungen den Zugriff zu gestatten. F\u00fcr MacOS galt das nicht, doch k\u00f6nnen nicht-privilegierte Anwendungen seit Version\u00a010.14 \u00fcber die Wildcard-Adresse\u00a00.0.0.0 auch an well-known Ports andocken. Den nicht auf Linux basierenden Betriebssystemen iOS und Windows ist die strikte Portnummern-basierte Blockade fremd.<\/p>\n