Volgens een recente commit die we ontdekten in het Android Open Source Project, bereidt Google zich voor om onderscheid te maken tussen het beveiligingspatchniveau van de leverancier en de Android Framework-beveiligingspatch niveau. Hierdoor kunnen OEM's Android up-to-date houden terwijl ze wachten tot hardwareleveranciers met oplossingen komen.
In zijn vroege geschiedenis had Android lange tijd de reputatie minder veilig te zijn dan iOS vanwege Apple's 'walled garden'-benadering van applicaties. Of die reputatie uit het verleden al dan niet terecht is, is niet iets waar we op ingaan, maar het is duidelijk dat Google grote vooruitgang heeft geboekt bij het beveiligen van Android tegen kwetsbaarheden. Het bedrijf biedt niet alleen nieuwe beveiligingsfuncties in de nieuwste versie van Android, Android P, maar ze bieden ook "beveiliging op bedrijfsniveau" op hun nieuwste apparaten dankzij een hardwarebeveiligingsmodule in de Google Pixel 2/2 XL. Om een apparaat veilig te houden, zijn ook voortdurende updates nodig om alle nieuwste bedreigingen te patchen, en daarom heeft Google dat ook gedaan
maandelijkse veiligheidsbulletins voor alle fabrikanten en leveranciers van apparaten om patches op te nemen tegen alle bekende actieve en potentiële kwetsbaarheden. Nu lijkt het erop dat het bedrijf mogelijk wijzigingen aanbrengt in het Android-beveiligingspatchsysteem door een manier te bieden om dit te doen maak onderscheid tussen het patchniveau van het Android-framework en het patchniveau van de leverancier samen met de bootloader, kernel, enz. om de beveiligingspatchniveaus te splitsen, zodat OEM's pure raamwerkupdates kunnen bieden, of om de gebruiker beter te kunnen identificeren welk patchniveau ze gebruiken.Maandelijkse Android-beveiligingspatches - een inleiding
We weten allemaal dat beveiligingspatches belangrijk zijn, vooral nadat in de tweede helft van vorig jaar een reeks spraakmakende kwetsbaarheden openbaar werd gemaakt. De BlueBorne-kwetsbaarheid viel het Bluetooth-protocol aan en werd gepatcht in de Maandelijkse patches van september 2017, KRAK richt zich op een zwakte in Wi-Fi WPA2 en is gepatcht December 2017, en de Spectre/Meltdown-kwetsbaarheden zijn grotendeels opgelost met de Patches van januari 2018. Het patchen van dergelijke kwetsbaarheden vereist doorgaans samenwerking met een hardwareleverancier (zoals Broadcom en Qualcomm) omdat de kwetsbaarheid een hardwarecomponent betreft, zoals de Wi-Fi- of Bluetooth-chip of de CPU. Aan de andere kant zijn er dergelijke problemen in het Android-besturingssysteem toast bericht overlay-aanval waarvoor alleen een update van het Android Framework nodig is om dit probleem op te lossen.
Telkens wanneer Google een maandelijkse beveiligingspatch uitrolt, zijn apparaatfabrikanten verplicht ALLE kwetsbaarheden te verhelpen zoals beschreven in het beveiligingsbulletin van die maand als ze willen zeggen dat hun apparaat tot die maandelijkse patch veilig is niveau. Elke maand zijn er twee beveiligingspatchniveaus waaraan een apparaat kan voldoen: het patchniveau op de 1e van de maand of de 5e van de maand. Als een apparaat zegt dat het een patchniveau gebruikt vanaf de 1e van de maand (bijv. 1 april in plaats van 5 april) betekent dat dat de build alle framework- EN leverancierspatches bevat van de release van de afgelopen maand plus alle framework-patches van het nieuwste beveiligingsbulletin. Aan de andere kant, als een apparaat zegt dat het een patchniveau heeft vanaf de 5e van de maand (bijvoorbeeld 5 april), ), dan betekent dit dat het alle framework- en leverancierspatches van vorige maand en deze maand bevat bulletin. Hier is een tabel die het fundamentele verschil tussen de maandelijkse patchniveaus illustreert:
Maandelijks beveiligingspatchniveau |
1 april |
5 april |
|---|---|---|
Bevat Framework-patches van april |
Ja |
Ja |
Bevat leverancierspatches van april |
Nee |
Ja |
Bevat March Framework-patches |
Ja |
Ja |
Bevat maart-leverancierspatches |
Ja |
Ja |
U bent waarschijnlijk bekend met de sombere situatie van de beveiligingspatches in het Android-ecosysteem. Onderstaande grafiek laat zien dat Google en Essential de snelste maandelijkse beveiligingspatchupdates bieden, terwijl andere bedrijven achterop raken. Het kan maanden duren voordat een OEM de nieuwste patches naar een apparaat brengt, zoals hoe de OnePlus5 en OnePlus5T onlangs ontvangen Beveiligingspatch van april toen ze eerder op de patch van december stonden.
Status van Android-beveiligingspatch vanaf februari 2018. Bron: @SecX13
Het probleem met het leveren van Android-beveiligingspatch-updates is niet noodzakelijkerwijs dat OEM's lui zijn, omdat ze er soms geen controle over hebben. Zoals we eerder vermeldden, vereisen maandelijkse updates van beveiligingspatches vaak de medewerking van hardware leverancier, wat vertragingen kan veroorzaken als de leverancier de maandelijkse beveiligingspatch niet kan bijhouden bulletins. Om dit tegen te gaan lijkt het erop dat Google het niveau van de Android Framework-beveiligingspatch gaat scheiden van het patchniveau van de leverancier (en mogelijk het bootloader- en kernelniveau), zodat OEM's in de toekomst mogelijk puur Android-framework-beveiliging kunnen bieden updates.
Snellere Android-beveiligingspatch-updates voor Framework-kwetsbaarheden?
Een nieuwe verbinden is verschenen in het Android Open Source Project (AOSP) gerrit dat verwijst naar een "leveranciersbeveiligingspatch". prop" die zou worden gedefinieerd in de Android.mk-bestanden wanneer er een nieuwe build voor een apparaat wordt gemaakt gemaakt. Dit pand heet "ro.vendor.build.security_patch"en zal analoog zijn aan"ro.build.version.security_patch" die momenteel op alle Android-apparaten bestaat om het maandelijkse Android-beveiligingspatchniveau te specificeren.
Dit nieuwe pand zal ons in plaats daarvan de "VENDOR_SECURITY_PATCH"-niveau van het apparaat, dat al dan niet overeenkomt met het Android Framework-beveiligingspatchniveau. Een apparaat kan bijvoorbeeld draaien op de nieuwste framework-patches van april 2018, samen met leverancierspatches van februari 2018. Door onderscheid te maken tussen de twee beveiligingspatchniveaus is het mogelijk dat Google van plan is OEM's de nieuwste Android OS-beveiligingspatches, ook al hebben leveranciers geen bijgewerkte patches voor die maandelijkse patch geleverd niveau.
alternatief, Googlen kan gewoon het minimum weergeven van de twee patchniveaus (naast mogelijk de bootloader- en kernelpatchniveaus) om de gebruiker nauwkeuriger te laten zien op welke beveiligingspatch zijn apparaat staat. We hebben nog geen bevestiging over de bedoeling achter deze patch, maar we hopen er binnenkort meer over te weten te komen.
Dit zal op zijn minst nuttig zijn voor degenen onder ons Project TrebleGenerieke systeemafbeeldingen (GSI's) en andere op AOSP gebaseerde aangepaste ROM's, aangezien aangepaste ROM's vaak alleen raamwerkupdates bieden zonder de hele leverancier te patchen, bootloader en kernelpatches die worden gespecificeerd in een maandelijks beveiligingsbulletin, dus de discrepantie veroorzaakt verwarring onder gebruikers omdat ze denken dat ze de nieuwste patches gebruiken, terwijl hun apparaat in werkelijkheid slechts gedeeltelijk is gepatcht tegen de nieuwste maandelijkse beveiliging bulletin.