Laut einem aktuellen Commit, den wir im Android Open Source Project entdeckt haben, bereitet Google sich darauf vor um zwischen dem Sicherheitspatch-Level des Herstellers und dem Android Framework-Sicherheitspatch zu unterscheiden Ebene. Dadurch können OEMs Android auf dem neuesten Stand halten, während sie darauf warten, dass Hardware-Anbieter Korrekturen bereitstellen.
Lange Zeit in seiner frühen Geschichte hatte Android aufgrund des „Walled Garden“-Ansatzes von Apple bei Anwendungen den Ruf, weniger sicher als iOS zu sein. Wir wollen uns nicht näher damit befassen, ob dieser frühere Ruf gerechtfertigt ist oder nicht, aber es ist klar, dass Google große Fortschritte beim Schutz von Android vor Schwachstellen gemacht hat. Das Unternehmen bietet nicht nur neue Sicherheitsfunktionen in der neuesten Android-Version, Android P, aber sie bieten auch „Sicherheit auf Unternehmensniveau" in ihren neuesten Geräten dank eines Hardware-Sicherheitsmoduls im Google Pixel 2/2 XL. Um die Sicherheit eines Geräts zu gewährleisten, sind auch kontinuierliche Updates erforderlich, um alle neuesten Bedrohungen zu patchen. Aus diesem Grund hat Google dies getan
Monatliche Android-Sicherheitspatches – eine Einführung
Wir alle wissen, dass Sicherheitspatches wichtig sind, insbesondere nachdem in der zweiten Hälfte des letzten Jahres eine Reihe hochkarätiger Sicherheitslücken bekannt wurden. Der BlueBorne-Sicherheitslücke hat das Bluetooth-Protokoll angegriffen und wurde darin gepatcht Monatliche Patches vom September 2017, KRACK zielt auf eine Schwachstelle in Wi-Fi WPA2 ab und wurde gepatcht Dezember 2017, und die Spectre/Meltdown-Schwachstellen wurden größtenteils mit behoben Patches vom Januar 2018. Das Patchen solcher Schwachstellen erfordert in der Regel die Zusammenarbeit mit einem Hardware-Anbieter (z. B. Broadcom). und Qualcomm), da die Schwachstelle eine Hardwarekomponente wie den WLAN- oder Bluetooth-Chip oder das betrifft CPU. Andererseits gibt es solche Probleme im Android-Betriebssystem Toast-Nachrichten-Overlay-Angriff Für die Behebung ist lediglich ein Update des Android Frameworks erforderlich.
Immer wenn Google einen monatlichen Sicherheitspatch herausbringt, müssen Gerätehersteller ALLE Schwachstellen beheben im Sicherheitsbulletin dieses Monats beschrieben, wenn sie sagen möchten, dass ihr Gerät bis zu diesem monatlichen Patch sicher ist Ebene. Jeden Monat gibt es zwei Sicherheitspatchstufen, die ein Gerät erfüllen kann: die Patchstufe am 1. des Monats oder am 5. des Monats. Wenn ein Gerät angibt, dass ab dem 1. des Monats ein Patch-Level ausgeführt wird (z. B. 1. April statt 5. April), dann bedeutet das, dass der Build alle Framework- UND Hersteller-Patches aus der Veröffentlichung des letzten Monats sowie alle Framework-Patches aus dem neuesten Sicherheitsbulletin enthält. Wenn ein Gerät hingegen angibt, dass ab dem 5. des Monats (z. B. 5. April) ein Patch-Level ausgeführt wird Beispiel), dann bedeutet das, dass es alle Framework- und Hersteller-Patches vom letzten und diesem Monat enthält Bekanntmachung. Hier ist eine Tabelle, die den grundlegenden Unterschied zwischen den monatlichen Patch-Levels veranschaulicht:
Monatlicher Sicherheitspatch-Level |
1. April |
5. April |
|---|---|---|
Enthält April-Framework-Patches |
Ja |
Ja |
Enthält April-Anbieter-Patches |
NEIN |
Ja |
Enthält März-Framework-Patches |
Ja |
Ja |
Enthält März-Händler-Patches |
Ja |
Ja |
Sie wissen wahrscheinlich, wie düster die Sicherheitspatch-Situation im Android-Ökosystem ist. Die folgende Grafik zeigt, dass Google und Essential die schnellsten monatlichen Sicherheitspatch-Updates bereitstellen, während andere Unternehmen zurückfallen. Es kann Monate dauern, bis ein OEM die neuesten Patches auf ein Gerät bringt, z. B. wie das OnePlus 5 und OnePlus 5T habe kürzlich die erhalten April-Sicherheitspatch als sie zuvor auf dem Dezember-Patch waren.
Stand des Android-Sicherheitspatches vom Februar 2018. Quelle: @SecX13
Das Problem bei der Bereitstellung von Android-Sicherheitspatch-Updates besteht nicht unbedingt darin, dass OEMs faul sind, da dies manchmal außerhalb ihrer Kontrolle liegen kann. Wie bereits erwähnt, erfordern monatliche Sicherheitspatch-Updates häufig die Mitarbeit einer Hardware Dies kann zu Verzögerungen führen, wenn der Anbieter nicht in der Lage ist, mit dem monatlichen Sicherheitspatch Schritt zu halten Bulletins. Um dem entgegenzuwirken, könnte Google damit beginnen, die Sicherheitspatch-Ebene des Android Framework von der Patch-Ebene des Herstellers zu trennen (und möglicherweise auf Bootloader- und Kernel-Ebene), sodass OEMs in Zukunft möglicherweise in der Lage sein könnten, reine Android-Framework-Sicherheit bereitzustellen Aktualisierung.
Schnellere Android-Sicherheitspatch-Updates für Framework-Schwachstellen?
Ein neuer begehen ist im Gerrit des Android Open Source Project (AOSP) aufgetaucht, das auf einen „Hersteller-Sicherheitspatch“ hinweist prop“, die in den Android.mk-Dateien definiert wird, wenn ein neuer Build für ein Gerät erstellt wird erstellt. Diese Eigenschaft wird „ro.vendor.build.security_patch" und wird analog sein zu "ro.build.version.security_patch", das derzeit auf allen Android-Geräten vorhanden ist, um die monatliche Android-Sicherheitspatch-Stufe anzugeben.
Diese neue Eigenschaft teilt uns stattdessen Folgendes mit:VENDOR_SECURITY_PATCH"-Stufe des Geräts, die möglicherweise mit der Sicherheitspatch-Stufe des Android Framework übereinstimmt. Beispielsweise kann ein Gerät mit den neuesten Framework-Patches vom April 2018 und den Hersteller-Patches vom Februar 2018 ausgeführt werden. Durch die Unterscheidung zwischen den beiden Sicherheitspatch-Stufen ist es möglich, dass Google beabsichtigt, OEMs den Versand zu überlassen die neuesten Sicherheitspatches für das Android-Betriebssystem, obwohl die Anbieter keine aktualisierten Patches für diesen monatlichen Patch bereitgestellt haben Ebene.
Alternative, Google zeigt möglicherweise nur das Minimum an der beiden Patch-Stufen (neben möglicherweise den Bootloader- und Kernel-Patch-Stufen), um dem Benutzer genauer anzuzeigen, auf welchem Sicherheitspatch sein Gerät installiert ist. Wir haben noch keine Bestätigung über die Absicht hinter diesem Patch, hoffen aber, bald mehr herauszufinden.
Zumindest wird dies für diejenigen von uns hilfreich sein Projekt TrebleGenerische Systembilder (GSIs) und andere AOSP-basierte benutzerdefinierte ROMs, da benutzerdefinierte ROMs häufig nur Framework-Updates bereitstellen, ohne den gesamten Hersteller zu patchen. Bootloader- und Kernel-Patches, die in einem monatlichen Sicherheitsbulletin angegeben werden, sodass die Nichtübereinstimmung bei den Benutzern Verwirrung stiftet Sie glauben, dass sie die neuesten Patches ausführen, obwohl ihr Gerät in Wirklichkeit nur teilweise mit den neuesten monatlichen Sicherheitspatches ausgestattet ist Bekanntmachung.