Ifølge en nylig forpliktelse vi oppdaget i Android Open Source Project, forbereder Google seg for å skille mellom leverandørens sikkerhetsoppdateringsnivå og Android Framework-sikkerhetsoppdateringen nivå. Dette lar OEM-er holde Android oppdatert mens de venter på at maskinvareleverandører skal gi feilrettinger.
I lang tid i sin tidlige historie hadde Android et rykte for å være mindre sikker enn iOS på grunn av Apples "walled garden"-tilnærming til applikasjoner. Hvorvidt det tidligere ryktet er fortjent eller ikke, er ikke noe vi skal dykke ned i, men det er klart at Google har gjort store fremskritt for å sikre Android mot sårbarheter. Ikke bare tilbyr selskapet nye sikkerhetsfunksjoner i den nyeste versjonen av Android, Android P, men de tilbyr også "sikkerhet i bedriftsklasse" i sine nyeste enheter takket være en maskinvaresikkerhetsmodul i Google Pixel 2/2 XL. Å holde en enhet sikker krever også kontinuerlige oppdateringer for å lappe alle de nyeste truslene, og det er derfor Google har
månedlige sikkerhetsbulletiner for alle enhetsprodusenter og -leverandører å innlemme patcher mot alle kjente aktive og potensielle sårbarheter. Nå ser det ut til at selskapet kan gjøre endringer i Android Security Patch-systemet ved å tilby en måte å skille mellom oppdateringsnivået for Android-rammeverket og oppdateringsnivået for leverandøren sammen med bootloader, kjerne osv. å enten dele sikkerhetsoppdateringsnivåene slik at OEM-er kan gi rene rammeverkoppdateringer eller bedre identifisere for brukeren hvilket oppdateringsnivå de kjører.Månedlige Android-sikkerhetsoppdateringer – en grunning
Vi vet alle at sikkerhetsoppdateringer er viktige, spesielt etter at en rekke høyprofilerte sårbarheter ble offentliggjort i andre halvdel av fjoråret. De BlueBorne sårbarhet angrep Bluetooth-protokollen og ble lappet i Månedlige patcher for september 2017, KRACK retter seg mot en svakhet i Wi-Fi WPA2 og ble lappet inn desember 2017, og Spectre/Meltdown-sårbarhetene ble stort sett fikset med Januar 2018-oppdateringer. Patching av sårbarheter som disse krever vanligvis samarbeid med en maskinvareleverandør (som Broadcom og Qualcomm) fordi sårbarheten gjelder en maskinvarekomponent som Wi-Fi- eller Bluetooth-brikken eller PROSESSOR. På den annen side er det problemer i Android-operativsystemet som dette toast melding overlegg angrep som bare krever en oppdatering til Android Framework for å fikse.
Hver gang Google lanserer en månedlig sikkerhetsoppdatering, er enhetsprodusentene pålagt å fikse ALLE sårbarhetene skissert i den månedens sikkerhetsbulletin hvis de vil si at enheten deres er sikker opp til den månedlige oppdateringen nivå. Hver måned er det to sikkerhetsoppdateringsnivåer som en enhet kan møte: oppdateringsnivået den 1. i måneden eller den 5. i måneden. Hvis en enhet sier at den kjører et oppdateringsnivå fra den 1. i måneden (f. 1. april i stedet for 5. april), så betyr det at bygget inneholder alle ramme- OG leverandøroppdateringer fra forrige måneds utgivelse pluss alle rammeverksoppdateringer fra den nyeste sikkerhetsbulletinen. På den annen side, hvis en enhet sier at den kjører et oppdateringsnivå fra den 5. i måneden (5. april, for eksempel), betyr det at den inneholder alle ramme- og leverandøroppdateringer fra forrige måned og denne månedens bulletin. Her er en tabell som eksemplifiserer den grunnleggende forskjellen mellom de månedlige patchnivåene:
Månedlig sikkerhetsoppdateringsnivå |
1. april |
5. april |
|---|---|---|
Inneholder April Framework Patcher |
Ja |
Ja |
Inneholder leverandørlapper fra april |
Nei |
Ja |
Inneholder March Framework Patcher |
Ja |
Ja |
Inneholder leverandørlapper fra mars |
Ja |
Ja |
Du er sikkert kjent med hvor dyster sikkerhetsoppdateringssituasjonen er i Android-økosystemet. Diagrammet nedenfor viser at Google og Essential gir de raskeste månedlige sikkerhetsoppdateringene mens andre selskaper faller bak. Det kan ta måneder for en OEM å bringe de nyeste oppdateringene til en enhet, for eksempel hvordan OnePlus 5 og OnePlus 5T nylig mottatt April sikkerhetsoppdatering da de tidligere var på desembers patch.
Android Security Patch-status fra februar 2018. Kilde: @SecX13
Problemet med å gi Android Security Patch-oppdateringer er ikke nødvendigvis at OEM-er er late, siden det noen ganger kan være utenfor deres kontroll. Som vi nevnte tidligere, krever månedlige sikkerhetsoppdateringer ofte samarbeid med en maskinvare leverandør, noe som kan forårsake forsinkelser hvis leverandøren ikke er i stand til å holde tritt med den månedlige sikkerhetsoppdateringen bulletiner. For å bekjempe dette ser det ut til at Google kan begynne å skille Android Framework-sikkerhetsoppdateringsnivået fra leverandørpatchnivået (og muligens oppstartslaster- og kjernenivå) slik at OEM-er i fremtiden kan være i stand til å gi ren Android-rammesikkerhet oppdateringer.
Raskere oppdateringer av Android Security Patch for Framework Vulnerabilities?
En ny begå har dukket opp i Android Open Source Project (AOSP) gerrit som antyder en "leverandørsikkerhetsoppdatering prop" som vil bli definert i Android.mk-filene når det bygges en ny enhet opprettet. Denne egenskapen vil bli kalt "ro.vendor.build.security_patch"og vil være analog med"ro.build.version.security_patch" som for øyeblikket finnes på alle Android-enheter for å spesifisere det månedlige Android Security Patch-nivået.
Denne nye eiendommen vil i stedet fortelle oss "VENDOR_SECURITY_PATCHnivået på enheten, som kanskje samsvarer med Android Framework sikkerhetsoppdateringsnivået. En enhet kan for eksempel kjøre på de siste rammeoppdateringene fra april 2018 sammen med leverandøroppdateringene fra februar 2018. Ved å skille mellom de to sikkerhetsoppdateringsnivåene, er det mulig at Google har til hensikt å la OEM-er sende siste Android OS-sikkerhetsoppdateringer selv om leverandører ikke har gitt oppdaterte oppdateringer for den månedlige oppdateringen nivå.
Alternativt, Google kan bare vise minimum av de to oppdateringsnivåene (ved siden av muligens oppstartslaster- og kjernepatch-nivåene) for mer nøyaktig å vise brukeren hvilken sikkerhetsoppdatering enheten deres er på. Vi har ennå ikke bekreftet intensjonen bak denne oppdateringen, men vi håper å finne ut mer snart.
I det minste vil dette være nyttig for oss som er på Prosjekt diskantGeneriske systembilder (GSI-er) og andre AOSP-baserte tilpassede ROM-er, som ofte gir tilpassede ROM-er bare rammeoppdateringer uten å lappe hele leverandøren, bootloader og kjernepatcher som er spesifisert i en månedlig sikkerhetsbulletin, så misforholdet forårsaker forvirring blant brukere når de tror de kjører de siste oppdateringene mens enheten deres i virkeligheten bare er delvis lappet mot den siste månedlige sikkerheten bulletin.