Enligt ett nyligen genomfört åtagande som vi upptäckte i Android Open Source Project förbereder sig Google för att skilja mellan leverantörens säkerhetskorrigeringsnivå och säkerhetskorrigeringen för Android Framework nivå. Detta låter OEM-tillverkare hålla Android uppdaterad medan de väntar på att maskinvaruleverantörer ska tillhandahålla korrigeringar.
Under en lång tid i sin tidiga historia hade Android ett rykte om sig att vara mindre säker än iOS på grund av Apples "walled garden"-inställning till applikationer. Huruvida det tidigare ryktet är välförtjänt eller inte är inget vi ska dyka in i, men det är uppenbart att Google har gjort stora framsteg för att säkra Android mot sårbarheter. Företaget tillhandahåller inte bara nya säkerhetsfunktioner i den senaste versionen av Android, Android P, men de tillhandahåller också "företagssäkerhet" i sina senaste enheter tack vare en hårdvarusäkerhetsmodul i Google Pixel 2/2 XL. Att hålla en enhet säker kräver också kontinuerliga uppdateringar för att korrigera alla de senaste hoten, vilket är anledningen till att Google har
Månatliga Android-säkerhetskorrigeringar - En primer
Vi vet alla att säkerhetskorrigeringar är viktiga, särskilt efter att en rad uppmärksammade sårbarheter offentliggjordes under andra halvan av förra året. De BlueBorne sårbarhet attackerade Bluetooth-protokollet och lappades i Månatliga patchar för september 2017, KRACK riktar sig mot en svaghet i Wi-Fi WPA2 och lappades in december 2017, och Spectre/Meltdown-sårbarheterna fixades mestadels med Januari 2018 patchar. Att patcha sårbarheter som dessa kräver vanligtvis samarbete med en hårdvaruleverantör (som Broadcom och Qualcomm) eftersom sårbarheten gäller en hårdvarukomponent som Wi-Fi- eller Bluetooth-kretsen eller CPU. Å andra sidan finns det problem i Android-operativsystemet som detta toast meddelande overlay attack som bara kräver en uppdatering av Android Framework för att fixa.
När Google rullar ut en månatlig säkerhetskorrigering måste enhetstillverkare fixa ALLA sårbarheter beskrivs i den månadens säkerhetsbulletin om de vill säga att deras enhet är säker upp till den månatliga patchen nivå. Varje månad finns det två säkerhetskorrigeringsnivåer som en enhet kan uppfylla: patchnivån den 1:a i månaden eller den 5:e i månaden. Om en enhet säger att den kör en patchnivå från den 1:a i månaden (t.ex. 1 april snarare än 5 april) så betyder det att byggnaden innehåller alla ram- OCH leverantörspatchar från förra månadens utgåva plus alla ram-patchar från den senaste säkerhetsbulletinen. Å andra sidan, om en enhet säger att den kör en patchnivå från den 5:e i månaden (5:e april, för exempel), betyder det att den innehåller alla ram- och leverantörskorrigeringar från förra månaden och denna månads bulletin. Här är en tabell som exemplifierar den grundläggande skillnaden mellan de månatliga patchnivåerna:
Månatlig säkerhetskorrigeringsnivå |
1 april |
5 april |
|---|---|---|
Innehåller April Framework Patchar |
Ja |
Ja |
Innehåller aprilförsäljarlappar |
Nej |
Ja |
Innehåller March Framework Patchar |
Ja |
Ja |
Innehåller March Vendor Patches |
Ja |
Ja |
Du är antagligen bekant med hur dyster säkerhetskorrigeringssituationen är i Androids ekosystem. Diagrammet nedan visar att Google och Essential tillhandahåller de snabbaste månatliga säkerhetsuppdateringarna medan andra företag hamnar på efterkälken. Det kan ta månader för en OEM att ta med de senaste patchar till en enhet, till exempel hur OnePlus 5 och OnePlus 5T nyligen fått April säkerhetskorrigering när de tidigare var på decembers patch.
Status för Android Security Patch i februari 2018. Källa: @SecX13
Problemet med att tillhandahålla Android Security Patch-uppdateringar är inte nödvändigtvis att OEM-tillverkare är lata, eftersom det ibland kan vara utom deras kontroll. Som vi nämnde tidigare kräver månatliga säkerhetsuppdateringar ofta samarbete med en hårdvara leverantör, vilket kan orsaka förseningar om leverantören inte kan hålla jämna steg med den månatliga säkerhetskorrigeringen bulletiner. För att bekämpa detta verkar det som att Google kan börja separera Android Framework-säkerhetspatchnivån från leverantörspatchnivån (och möjligen bootloader- och kärnnivån) så att OEM-tillverkare i framtiden kan tillhandahålla ren Android-ramsäkerhet uppdateringar.
Snabbare uppdateringar av Android Security Patch för Framework Vulnerabilities?
En ny begå har dykt upp i Android Open Source Project (AOSP) gerrit som antyder en "leverantörssäkerhetspatch prop" som skulle definieras i Android.mk-filerna när en ny konstruktion för en enhet pågår skapat. Den här egenskapen kommer att kallas "ro.vendor.build.security_patch"och kommer att vara analog med"ro.build.version.security_patch" som för närvarande finns på alla Android-enheter för att ange den månatliga Android Security Patch-nivån.
Den här nya egenskapen kommer istället att berätta för oss "VENDOR_SECURITY_PATCHnivån på enheten, som kanske inte matchar säkerhetskorrigeringsnivån för Android Framework. En enhet kan till exempel köras med de senaste ramar för april 2018 tillsammans med leverantörspatchar från februari 2018. Genom att skilja mellan de två säkerhetskorrigeringsnivåerna är det möjligt att Google avser att låta OEM-tillverkare skicka senaste Android OS-säkerhetskorrigeringar även om leverantörer inte har tillhandahållit uppdaterade korrigeringar för den månatliga korrigeringen nivå.
Alternativt, Google kanske bara visar minimum av de två patchnivåerna (tillsammans med möjligen bootloader- och kärn-patchnivåerna) för att mer exakt visa för användaren vilken säkerhetskorrigering deras enhet är på. Vi har ännu ingen bekräftelse på avsikten bakom denna patch, men vi hoppas få reda på mer snart.
Åtminstone kommer detta att vara till hjälp för oss Projekt TrebleGeneriska systembilder (GSI) och andra AOSP-baserade anpassade ROM, eftersom anpassade ROM ofta endast tillhandahåller ramverksuppdateringar utan att patcha hela leverantören, bootloader och kärnpatchar som anges i en månatlig säkerhetsbulletin, så oöverensstämmelsen orsakar förvirring bland användarna när de tror att de kör de senaste patcharna när deras enhet i verkligheten bara delvis är patchad mot den senaste månadssäkerheten bulletin.