Frage zu GrapheneOS - Vendor-Partition

Moin :slight_smile:!

Ich würde gerne einmal auf den folgenden Heise Artikel verlinken

https://www.heise.de/news/Malware-ab-Werk-Android-Trojaner-vermietet-Opfer-Smartphones-minutenweise-9057015.html

und einen Kommentar eines User hier einmal zitieren, solange das hier erlaubt ist:

" Selbst ein Open Source Android hilft da nicht.

Das Installationsmodell moderner Android Handys sieht so aus.

ROM: Master Bootloader
Flash: Partitionstabelle:

  1. Bootloader A
  2. Kernel A
  3. Android Systempartition A
  4. Vendor Partition A
  5. Bootloader B
  6. Kernel B
  7. Android Systempartition B
  8. Vendor Partition B
  9. Android Datenpartition

(1,2,3,4 gibts jeweils 2mal als A/B) User-daten werden ausschliesslich in „9“ abgelegt - verschlüsselt.
Beim „Fabrik-rücksetzen“ wird 9 gelöscht/ neu formatiert, was das gerät auf qquasi Auslieferungszustand zurücksetzt, aber die jeweilige Firmware und das System beibehält

Wenn jetzt ein Update vom Hersteller verteilt wird, ist das ein patch, d.h. wenn gerade das System von Slot A geladen ist, wird das in Slott B kopiert (oder umgekehrt)und der patch angewendet. War das erfolgreich wird ab dem nächsten Boot der jeweils neuere Slot verwendet, sonst erfolgt ein „rollback“ also weiter der alte. Meist werden dabei nur das von Google gelieferte System upgedated und der Rest bleibt wies ist.

In der Vendor-partition sind dabei Herstellerspezifische Firmware-images, also etwa der Microcode fürs Modem, verschlüsselter, signierter Code für die Snapdragon secure enclave (die etwa secure boot Funktionen umsetzt) und dergleichen.

Wenn man jetzt ein offenes Android draufmacht, dann wird dabei alles überscrieben ausser der vendor-partition, da es für diese Firmware images quasi nie offene Quellen gibt (die neue EU Radio Richtlinie verbietet das sogar afaik, weil sonst die CE zertifizierung erlöscht)

Leider ist genau jene Firmware verwanzt, und das sag ich schon seit Jahren. Teilweise gezielt vom Hersteller, teilweise von dritten die ein Kuckuksei gelegt haben. Da der Code untehalb der jeweiligen Linux Kernel-eben läuft (z.B. in der Snapdragon Secure Enclave) ist das für das Linux Kernel nicht sichtbar, umgekehrt hat der Code aber vollzugriff auf den ganzen geräte RAM.

Das ist in der Security Szene seit langem bekannt. Es gab auch schon mehrere Exploits die auf diese Secure Enclave abzielen um auf dieser Ebene ein gerät zu übernehmen, was sämtliche Android Sicherheitsfeatures aushebelt."

Heißt das nun, dass auch ein GrapheneOS diese Vendor-Partition nicht überschreiben kann? Ich habe auf den ersten Klick nichts konkretes dazu gefunden?
Wäre ja ein No-Go …

Würde mich über eine Erklärung freuen, falls jemand mehr dazu weiß :slight_smile:
Viele Grüße

@Layer8 Grundsätzlich ist einiges an dieser Feststellung richtig. Heutzutage sind alle Computerchips wie CPUs proprietär und auch Bootloader (oder UEFI) meist. Bei ARM (in fast allen Android-Geräten verbaut) kommt noch erschwerend hinzu, dass aus Lizenzgründen nicht mal ein Nischenhersteller seine Schaltungen veröffentlichen darf. Wenn du einen möglichst freien Computer haben willst, kannst du dir mal Talos II von Raptor anschauen.
Ebenso erfordern andere Bauteile, insbesondere Funkchips für WLAN, Mobilfunk usw. unfreie Firmware. Das ist auch nicht exklusiv bei Android/GrapheneOS so, mein Laptop braucht für die WLAN-Karte eine proprietäre Firmware, die GPU glaube ich auch.

Also haben wir aktuell bis auf Nischenprodukte (nicht alltagstauglich, auf jeden Fall nicht geeignet für Smartphones) die Wahl zwischen unfreier Firmware und unfreier Firmware. Daher sorgt Google dafür, dass zuverlässig jeden Monat im garantierten Supportzeitraum Updates kommen, fast immer auch Pixel-spezifische Patches. Das sind dann Updates an (Pixel-spezifischer) Firmware und kommen in die Vendor-Partition.
Damit der Updateprozess sicher ist, werden alle Komponenten über eine Chain of Trust („Secure Boot“) bei jedem Bootvorgang auf eine gültige Signatur überprüft. Das ist übrigens einer der Gründe, wieso Niemand außer Google diese Updates bereitstellen kann und GrapheneOS den Support zeitgleich zu Google einstellen muss.
Die Alternative, keine Updates für proprietäre Firmware einzuspielen, wäre fatal. Schließlich läuft auf dem ausgelieferten Modell schon ähnliche Firmware, nur halt mit offenen Sicherheitslücken. Das kann dann auch manchmal eine kritische Remote Code Execution Lücke sein.

Wie der Artikel schon selbst sagt, sollte man sich an bekannte Hersteller wie Samsung oder Google halten. Übrigens kann man trotz proprietärem Code wunderbar Netzwerktraffic beobachten, macht Mike ja auch ständig. Also würde es Sicherheitsforschern durchaus auffallen, wenn Pixel-Geräte unerklärliche Netzwerkverbindungen aufbauen.

Siehe auch GrapheneOS’s Antwort auf die Frage, wieso aktuell nur Pixel-Geräte unterstützt werden.

2 „Gefällt mir“

Danke dir für deine ausführliche Antwort!! Finde die Thematik ganz interessant, werde ich mal etwas tiefer einsteigen :slight_smile:

1 „Gefällt mir“