Aktivitäten von GrapheneOS in sozialen Netzwerken
- GrapheneOS ist Teil eines dezentralen sozialen Netzwerks auf Basis von Mastodon.
- Es betreibt einen GrapheneOS-Server für das offizielle Projektkonto und Projektmitglieder.
- Der Server hat 5 aktive Nutzer.
Hardware-Unterstützung für Memory Tagging auf Pixel 8 und Pixel 8 Pro
- Auf Pixel 8 und Pixel 8 Pro wurde dank Hardware-Unterstützung für Memory Tagging ein Bug mit Speicherbeschädigung in Bluetooth LE von Android 14 QPR2 entdeckt.
- Derzeit wird der Bug untersucht, um ihn zu beheben oder als Workaround eine neu eingeführte Funktion vorübergehend zu deaktivieren.
Deaktivierung von Memory Tagging ist als temporäre Lösung ungeeignet
- Das Problem tritt nur bei bestimmten Bluetooth-LE-Geräten auf, nicht bei allen Bluetooth-Geräten.
- Memory Tagging für diesen Prozess zu deaktivieren, ist selbst als kurzfristige Lösung nicht akzeptabel.
Entwicklung eines Bugfixes für Android 14 QPR2
- Es wurde ein Use-after-free-Bug im Zusammenhang mit Bluetooth LE gefunden und ein Patch entwickelt.
- Priorität hat, die Korrektur in GrapheneOS-Releases aufzunehmen; außerdem soll sie als Android-Sicherheitsbug gemeldet werden.
- Es wird erwartet, dass damit auch Probleme mit BLE-Audio behoben werden.
Bestätigung der Fehlerbehebung
- Ein Nutzer mit Samsung Galaxy Buds2 Pro konnte das Problem im Bluetooth-LE-Modus reproduzieren und bestätigen, dass die Korrektur wirksam ist.
- Das Problem betrifft auch das Standard-Pixel-OS.
- GrapheneOS erkannte dies durch Memory-Tagging-Unterstützung in
hardened_malloc und fügte Funktionen hinzu, um MTE-Absturzbenachrichtigungen und Berichte zu senden.
Meldung als Sicherheitsbug
- Das Use-after-free-Problem wurde als Sicherheitsbug gemeldet (b/328916844 für Google-Mitarbeitende).
- Ein anfänglicher minimalinvasiver Patch wurde bereitgestellt.
- Der Code benötigt ein größeres Refactoring und sollte keine rohen Pointer verwenden, aber mit einem schnellen Patch soll vermieden werden, neue Bugs einzuführen.
Portierung des Bluetooth-Codes nach Rust
- Android hat bereits viel Bluetooth-Code nach Rust portiert.
- Für die Portierung des restlichen Codes nach Rust sollten mehr Ressourcen eingesetzt werden.
- HWASan- und MTE-Builds sollten in verschiedenen realen Nutzungsszenarien getestet werden.
Bedeutung von MTE
- Pixels bieten mit MTE eine wichtige hardwarebasierte Sicherheitsfunktion, die im OS nicht aktiviert wird, um 3,125 % bei Speicher-/Cache-Nutzung einzusparen.
- GrapheneOS aktiviert MTE standardmäßig für das Basis-OS und bekannte kompatible vom Nutzer installierte Apps.
- Nutzer können MTE in den Einstellungen für alle vom Nutzer installierten Apps aktivieren.
MTE-Implementierung von GrapheneOS
- GrapheneOS bietet als Teil von
hardened_malloc eine bessere MTE-Implementierung mit standardmäßigen zufälligen Tags und einem dedizierten Free-Tag.
- Die Integration von Chromium wurde korrigiert, und es ist geplant, PartitionAlloc zu verbessern.
Einsatz von MTE durch GrapheneOS
- GrapheneOS ist die erste Plattform, die MTE in der Produktionsumgebung einsetzt.
- Der Vanadium-Browser ist der erste Browser, der MTE in der Produktionsumgebung einsetzt.
- Geplant sind die Ergänzung von Stack-MTE, die Verbesserung von PartitionAlloc und ein neues Kernel-Slab-MTE.
Dank der Nutzer
- Nutzer äußerten Dankbarkeit für die automatische Bluetooth-Deaktivierungsfunktion von GrapheneOS.
Meinung von GN⁺
- GrapheneOS ist ein auf Android basierendes, sicherheitsorientiertes Betriebssystem und zeigte, dass es den auf aktuellen Pixel-Geräten entdeckten Bug mit Speicherbeschädigung schnell erkennen und darauf reagieren kann.
- Diese schnelle Reaktion zeigt die Vorteile der Open-Source-Community deutlich und trägt dazu bei, den Nutzern eine sicherere mobile Umgebung zu bieten.
- Die Portierung von Code in die speichersichere Sprache Rust ist ein wichtiger Schritt für eine langfristige Stärkung der Sicherheit.
- Die Aktivierung der hardwarebasierten Sicherheitsfunktion MTE ist eine effektive Methode, um die Sicherheit zu erhöhen und Leistungseinbußen dabei möglichst gering zu halten.
- Bei der Einführung dieser Technik sollte die Kompatibilität mit bestehenden Anwendungen berücksichtigt werden; außerdem sind angemessene Tests und Wartung für eine stärkere Sicherheit erforderlich.
1 Kommentare
Hacker-News-Kommentare
Die Memory Tagging Extension ist standardmäßig nicht aktiviert, kann aber von jeder Person über die Entwickleroptionen eingeschaltet werden. Man kann sie einmalig aktivieren, wenn man eine bestimmte App testen möchte, oder sie so lange eingeschaltet lassen, wie man will.
Erwartet werden Antworten von GrapheneOS-Nutzern darauf, ob die Installation von Graphene OS schwierig ist, ob ein spezielles Kabel nötig ist, ob man sich gut mit Android-Geräten auskennen muss oder ob es reicht, einfach den Anweisungen zu folgen.
Bitte um Erfahrungsberichte dazu, ob es unpraktisch ist, Graphene OS im Alltag zu nutzen, ob das Telefon häufig abstürzt und man tagelang debuggen muss und ob Banking-Apps funktionieren.
Verwunderung darüber, wie das Pixel-Team die Entscheidung rechtfertigt, eine wichtige Hardware-Sicherheitsfunktion (MTE) im OS nicht zu aktivieren, um 3,125 % beim Speicher-/Cache-Verbrauch zu sparen. Heap-MTE hat im asynchronen Modus nahezu keinen Performance-Overhead und ist im asymmetrischen Modus günstiger als bestehende Schutzmechanismen mit abnehmender Wirksamkeit wie SSP.
Frage nach einem Vergleich der Sicherheitstechnologien MTE und CHERI.
GrapheneOS ist in Sicherheitsfragen anderen Lösungen weit voraus, sodass die Entscheidung für etwas anderes als Pixel-Hardware fragwürdig erscheint. Gleichzeitig wird der starke Wunsch nach einem austauschbaren Akku geäußert.
Frage, ob Single-Board-Computer wie aktuelle Raspberry Pi Arm MTE implementieren.
Warten auf Mainstream-Hardware, die Speicherkorruptionsprobleme lösen kann, ähnlich wie die Memory-Tag-Architektur von Solaris SPARC aus dem Jahr 2015 oder früher. Diese Probleme werden größtenteils von Entwicklern mit unzureichenden Fähigkeiten verursacht.
2024 braucht es Betriebssysteme, Anwendungen und Tools, die den Geist von seL4 übernehmen und zugleich strenger formal verifiziert sind. Wie bisher unzureichend getestete und überengineerte Codebasen als Systeme einzusetzen, bringt Risiken für Nutzer mit sich und schafft eine große Angriffsfläche für Bugs, Malware und Hacks.
Wenn keine saubere, integrierte User Experience (UX) und nutzbare Funktionen geboten werden, ist alle Ingenieursarbeit vergeblich.
Android hat einen erheblichen Teil des Bluetooth-Codes nach Rust portiert. Das zeigt, dass mehr Ressourcen in die Portierung weiteren Codes nach Rust investiert werden sollten.
Jemand mit langjähriger Erfahrung in C und C++, aber ohne Rust-Erfahrung, fragt sich, wie viel Refactoring beim Portieren von C nach Rust nötig ist. Außerdem die Frage, wie Google dabei vorgeht: ob man versucht, so direkt wie möglich zu „übersetzen“, oder ob man es als Gelegenheit für größere Rewrites bzw. Refactorings sieht.
Neugier, ob der Android-Bluetooth-Stack auf Desktop-Systemen mit Standard-Linux-Distributionen verwendet werden kann.