Ifølge en nylig tilsagn, vi opdagede i Android Open Source Project, forbereder Google sig for at skelne mellem leverandørsikkerhedspatch-niveauet og Android Framework-sikkerhedspatchen niveau. Dette lader OEM'er holde Android opdateret, mens de venter på, at hardwareleverandører leverer rettelser.
I lang tid i sin tidlige historie havde Android ry for at være mindre sikker end iOS på grund af Apples "walled garden" tilgang til applikationer. Hvorvidt det tidligere omdømme er fortjent eller ej, er ikke noget, vi skal dykke ned i, men det er klart, at Google har gjort store fremskridt med at sikre Android mod sårbarheder. Ikke alene leverer virksomheden nye sikkerhedsfunktioner i den nyeste version af Android, Android P, men de leverer også "sikkerhed i virksomhedsklasse" i deres nyeste enheder takket være et hardwaresikkerhedsmodul i Google Pixel 2/2 XL. At holde en enhed sikker kræver også løbende opdateringer for at lappe alle de seneste trusler, hvilket er grunden til, at Google har månedlige sikkerhedsbulletiner
for alle enhedsproducenter og -leverandører til at inkorporere patches mod alle kendte aktive og potentielle sårbarheder. Nu ser det ud til, at virksomheden muligvis foretager ændringer i Android Security Patch-systemet ved at tilbyde en måde at skelne mellem Android framework-patch-niveauet og leverandør-patch-niveauet sammen med bootloaderen, kernen osv. enten at opdele niveauerne for sikkerhedsrettelser, så OEM'er kan levere rene rammeopdateringer eller bedre identificere over for brugeren, hvilket patchniveau de kører.Månedlige Android-sikkerhedsrettelser - en primer
Vi ved alle, at sikkerhedsrettelser er vigtige, især efter at en række højprofilerede sårbarheder blev offentliggjort i anden halvdel af sidste år. Det BlueBorne sårbarhed angreb Bluetooth-protokollen og blev lappet i September 2017 månedlige patches, KRACK retter sig mod en svaghed i Wi-Fi WPA2 og blev rettet ind december 2017, og Spectre/Meltdown-sårbarhederne blev for det meste rettet med januar 2018 patches. Patching af sårbarheder som disse kræver typisk samarbejde med en hardwareleverandør (såsom Broadcom og Qualcomm), fordi sårbarheden vedrører en hardwarekomponent, såsom Wi-Fi- eller Bluetooth-chippen eller CPU. På den anden side er der problemer i Android-operativsystemet som dette toast besked overlejring angreb som kun kræver en opdatering til Android Framework for at løse problemet.
Når Google udruller en månedlig sikkerhedspatch, er enhedsproducenterne forpligtet til at rette ALLE sårbarhederne beskrevet i den måneds sikkerhedsbulletin, hvis de vil sige, at deres enhed er sikker op til den månedlige patch niveau. Hver måned er der to sikkerhedspatch-niveauer, som en enhed kan opfylde: patch-niveauet den 1. i måneden eller den 5. i måneden. Hvis en enhed siger, at den kører et patch-niveau fra den 1. i måneden (f. 1. april i stedet for 5. april), så betyder det, at buildet indeholder alle ramme- OG leverandørpatches fra sidste måneds udgivelse plus alle framework-patches fra den nyeste sikkerhedsbulletin. På den anden side, hvis en enhed siger, at den kører et patch-niveau fra den 5. i måneden (5. april, f.eks. eksempel), betyder det, at den indeholder alle ramme- og leverandørpatches fra sidste måned og denne måneds opslag. Her er en tabel, der eksemplificerer den grundlæggende forskel mellem de månedlige patch-niveauer:
Månedligt sikkerhedspatch-niveau |
første april |
5. april |
|---|---|---|
Indeholder April Framework Patches |
Ja |
Ja |
Indeholder leverandørpatches fra april |
Ingen |
Ja |
Indeholder March Framework Patches |
Ja |
Ja |
Indeholder March Vendor Patches |
Ja |
Ja |
Du er sikkert bekendt med, hvor trist sikkerhedspatch-situationen er i Android-økosystemet. Diagrammet nedenfor viser, at Google og Essential leverer de hurtigste månedlige sikkerhedsopdateringer, mens andre virksomheder kommer bagud. Det kan tage måneder for en OEM at bringe de nyeste patches til en enhed, såsom hvordan OnePlus 5 og OnePlus 5T for nylig modtaget April sikkerhedsopdatering da de tidligere var på decembers patch.
Status for Android Security Patch i februar 2018. Kilde: @SecX13
Problemet med at levere Android Security Patch-opdateringer er ikke nødvendigvis, at OEM'er er dovne, da det nogle gange kan være ude af deres kontrol. Som vi nævnte tidligere, kræver månedlige sikkerhedsopdateringer ofte samarbejde med en hardware leverandør, hvilket kan forårsage forsinkelser, hvis leverandøren ikke er i stand til at følge med den månedlige sikkerhedsrettelse bulletiner. For at bekæmpe dette ser det ud til, at Google kan begynde at adskille Android Framework-sikkerhedspatch-niveauet fra leverandør-patch-niveauet (og muligvis bootloader- og kerneniveauet), så OEM'er i fremtiden muligvis kan levere ren Android-rammesikkerhed opdateringer.
Hurtigere Android Security Patch-opdateringer til Framework-sårbarheder?
En ny begå har dukket op i Android Open Source Project (AOSP) gerrit, der antyder en "leverandørsikkerhedspatch prop", som ville blive defineret i Android.mk-filerne, når der bygges en ny enhed til en enhed oprettet. Denne ejendom vil blive kaldt "ro.vendor.build.security_patch"og vil være analog med"ro.build.version.security_patch", som i øjeblikket findes på alle Android-enheder for at angive det månedlige Android Security Patch-niveau.
Denne nye ejendom vil i stedet fortælle os "VENDOR_SECURITY_PATCH"-niveauet på enheden, som muligvis matcher Android Framework-sikkerhedspatch-niveauet. For eksempel kan en enhed køre på de seneste rammerettelser fra april 2018 sammen med leverandørpatches fra februar 2018. Ved at skelne mellem de to sikkerhedsrettelsesniveauer er det muligt, at Google har til hensigt at lade OEM'er sende seneste Android OS sikkerhedsrettelser, selvom leverandører ikke har leveret opdaterede patches til den månedlige patch niveau.
Alternativt, Google kan kun vise minimum af de to patch-niveauer (sammen med muligvis bootloader- og kernel patch-niveauer) for mere præcist at vise brugeren, hvilken sikkerhedspatch deres enhed er på. Vi har endnu ikke bekræftelse på hensigten bag denne patch, men vi håber at finde ud af mere snart.
Dette vil i det mindste være nyttigt for dem af os på Projekt DiskantGeneriske systembilleder (GSI'er) og andre AOSP-baserede brugerdefinerede ROM'er, da brugerdefinerede ROM'er ofte kun giver rammeopdateringer uden at patche hele leverandøren, bootloader og kernepatches, der er specificeret i en månedlig sikkerhedsbulletin, så uoverensstemmelsen forårsager forvirring blandt brugerne, da de tror, de kører de nyeste patches, mens deres enhed i virkeligheden kun er delvist patchet mod den seneste månedlige sikkerhed opslag.