Slik fungerer månedlige Android Security Patch-oppdateringer

Google har publisert månedlige sikkerhetsbulletiner siden august 2015. Disse sikkerhetsbulletinene inneholder en liste over avslørte sikkerhetssårbarheter som er fikset som påvirker Android-rammeverket, Linux-kjernen og andre leverandørkomponenter med lukket kildekode. Hver sårbarhet i bulletinene ble enten oppdaget av Google eller opplyst til selskapet. Hver sårbarhet som er oppført har et Common Vulnerabilities and Exposures (CVE)-nummer, sammen med tilhørende referanser, typen sårbarhet, en alvorlighetsvurdering og den berørte AOSP-versjonen (hvis aktuelt). Men til tross for den tilsynelatende forenklede prosessen bak hvordan Android-sikkerhetsoppdateringer fungerer, er det faktisk noe komplisert frem og tilbake bak kulissene som gjør at telefonen din kan bli månedlig eller (forhåpentligvis) nesten månedlig lapper.

Hva gjør egentlig en sikkerhetsoppdatering?

Du har kanskje lagt merke til at det faktisk er det hver måned to sikkerhetsoppdateringsnivåer. Formatet på disse oppdateringene er enten ÅÅÅÅ-MM-01 eller ÅÅÅÅ-MM-05. Mens YYYY og MM åpenbart representerer henholdsvis år og måned, betyr "01" og "05" forvirrende nok ikke dagen i måneden da sikkerhetsoppdateringsnivået ble utgitt. I stedet er 01 og 05 faktisk to forskjellige sikkerhetsoppdateringsnivåer utgitt på samme dag hver måned - oppdateringsnivået med 01 på slutten inneholder rettelser til Android-rammeverket, men ikke leverandørpatcher eller oppstrøms Linux-kjernepatcher. Leverandørpatcher, som vi definerte ovenfor, refererer til rettelser til komponenter med lukket kildekode, for eksempel drivere for Wi-Fi og Bluetooth. Sikkerhetsoppdateringsnivået betegnet med -05 inneholder disse leverandørpatchene så vel som patcher i Linux-kjernen. Ta en titt på tabellen nedenfor som kan hjelpe deg med å forstå.

Selvfølgelig kan noen OEM-er velge å rulle sine egne patcher og oppdateringer inn i sikkerhetsoppdateringer også. De fleste OEM-er har sin egen versjon av Android, så det er bare fornuftig at du for eksempel kan ha en sårbarhet på en Samsung-telefon som ikke finnes på en Huawei. Mange av disse OEM-ene publiserer også sine egne sikkerhetsbulletiner.

• Google Pixel
• Huawei
• LG
• Motorola
• HMD Global
• Samsung

Tidslinjen for en sikkerhetsoppdatering fra Google til telefonen din

Sikkerhetsoppdateringer har en tidslinje som spenner over omtrent 30 dager, men ikke alle OEM kan benytte seg av hele tidslinjen. La oss ta en titt på mai 2019 sikkerhetsoppdatering for eksempel, og vi kan bryte ned hele tidslinjen bak opprettelsen av denne oppdateringen. Bedrifter liker Viktig klarer å få ut sikkerhetsoppdateringene deres på samme dag som Google Pixel, så hvordan gjør de det? Det korte og enkle svaret er at de er en Android-partner. Sikkerhetsbulletinen for mai 2019 ble publisert 6. mai, med både Google Pixels og Essential Phone som får nesten umiddelbare oppdateringer.

Hva det betyr å være en Android-partner

Ikke et hvilket som helst selskap kan være en Android-partner, selv om i utgangspunktet alle store Android OEM er det. Android-partnere er selskapene som får lisens til å bruke Android-merkevaren i markedsføringsmateriell. De har også lov til å sende Google Mobile Services (GMS – refererer til stort sett alle Google-tjenester) så lenge de oppfyller kravene som er beskrevet i Compatibility Definition Document (CDD) og bestå Compatibility Test Suite (CTS), Vendor Test Suite (VTS), Google Test Suite (GTS) og noen få andre tester. Det er tydelige forskjeller i sikkerhetsoppdateringsprosessen for selskaper som er det ikke en Android-partner.

• Android-rammeverkoppdateringer er tilgjengelige for dem etter å ha blitt slått sammen til AOSP 1–2 dager før sikkerhetsbulletinen utgis.
• Oppstrøms Linux-kjerneoppdateringer kan velges når de er tilgjengelige.
• Rettelser fra SoC-leverandører for komponenter med lukket kildekode er tilgjengelig avhengig av avtaler med SoC-leverandøren. Merk at hvis leverandøren har gitt OEM-tilgang til kildekoden til komponenten(e) med lukket kildekode, kan OEM-en selv fikse problemet(e). Hvis OEM ikke har tilgang til kildekoden, må de vente på at leverandøren utsteder en løsning.

Hvis du er en Android-partner, har du det umiddelbart mye enklere. Android-partnere blir varslet om alle problemer med Android-rammeverk og Linux-kjerneproblemer minst 30 dager før bulletinen offentliggjøres. Google tilbyr patcher for alle problemer for OEM-er å slå sammen og teste, selv om leverandørkomponentpatcher er avhengige av leverandøren. Patcher for Android-rammeverksproblemene som ble avslørt i sikkerhetsbulletinen fra mai 2019, ble for eksempel levert til Android-partnere minst så tidlig som 20. mars 2019*. Det er en mye av ekstra tid.

*Merk: Google kan, og gjør det ofte, oppdatere oppdateringene for den siste sikkerhetsbulletinen helt frem til den offentlige utgivelsen. Disse oppdateringene kan skje hvis nye sårbarheter og feil har blitt funnet, hvis Google bestemmer seg for å fjerne visse oppdateringer fra den månedlige bulletinen på grunn av at den bryter kritiske komponenter, hvis Google oppdaterer en oppdatering for å løse en feil opprettet av den forrige versjonen av oppdateringen, og andre grunner.

Hvorfor må jeg vente så lenge på å motta en sikkerhetsoppdatering på telefonen min?

Selv om det er sant at Android-partnere (les: alle store OEM-er) mottok sikkerhetsoppdateringer i god tid før de utgivelsen, er mange smertelig klar over at de muligens ikke vil motta en sikkerhetsoppdatering på flere måneder etter den utgivelse. Dette er generelt ned til én av fire grunner.

• OEM-er må kanskje gjøre tunge tekniske endringer for å imøtekomme en sikkerhetsoppdatering, da den kan komme i konflikt med eksisterende kode.
• Leverandøren er treg med å gi oppdateringskildekode for komponenter med lukket kildekode.
• Transportørsertifisering kan ta tid.
• Bedrifter kan være uvillige til å gi ut en sikkerhetsoppdatering uten også å slippe en funksjon samtidig.

Selv om alle disse er gyldige grunner for at en bedrift ikke skal gi ut en sikkerhetsoppdatering, bryr ikke sluttbrukeren seg alltid om noen av disse. Riktignok bryr ikke sluttbrukeren seg alltid om sikkerhetsoppdateringer heller, selv om de burde. Initiativer som Project Treble, utvidet Linux LTS, og Prosjekt hovedlinje bidrar til å eliminere de tekniske vanskelighetene med å slå sammen disse sikkerhetsoppdateringene, men det er ikke nok til å få OEM-er til å konsekvent strebe etter å legge ut oppdateringer. Med et generisk kjernebilde, eller GKI, vil SoC-leverandører og OEM-er ha lettere for å slå sammen oppstrøms Linux-kjernepatcher, selv om vi sannsynligvis ikke vil se de første enhetene med GKI før neste år.

Men en interessant informasjon som de fleste ikke vet, er at store OEM-er må gi "minst fire sikkerhetsoppdateringer" innen et år etter en enhets lansering, og 2 år med oppdateringer totalt sett. Google har ikke bekreftet disse spesifikke vilkårene, men selskapet bekreftet at de «arbeidet med å bygge sikkerhetsoppdateringer inn i [deres] OEM-avtaler». Når det gjelder Android Enterprise Recommended (AER)-enheter, må enhetene få sikkerhetsoppdateringer innen 90 dager etter utgivelse i 3 år. Robuste AER-enheter kreves for å få 5 år av sikkerhetsoppdateringer. Android One-enheter er ment å få sikkerhetsoppdateringer hver måned i 3 år.

Hva er i en sikkerhetsoppdatering?

En sikkerhetsoppdatering er bare en annen oppdatering, men generelt mye mindre med endringer i individuelle rammeverk og systemmoduler i stedet for systemomfattende forbedringer eller endringer. Hver måned gir Google enhets-OEM-er en zip-fil som inneholder oppdateringer for alle større Android-versjoner som fortsatt støttes, sammen med en sikkerhetstestpakke. Denne testpakken hjelper OEM-er med å fange hull i sikkerhetsoppdateringer, for å sikre at de ikke går glipp av noe og at lappene ble slått sammen på riktig måte. Etter hvert som måneden går, kan Google gjøre mindre revisjoner som å bestemme at én spesifikk oppdatering er valgfri, spesielt hvis det er problemer med å implementere den.

Hva med tilpassede ROM-er?

Hvis smarttelefonen din ikke får mange sikkerhetsoppdateringer, betyr det ikke nødvendigvis at du er bedre å bytte til en tilpasset ROM. Selv om det er sant at du vil få sikkerhetsoppdateringer som du ellers ikke ville ha fått, er det bare halvparten av historien. Å låse opp bootloaderen gjør deg utsatt for fysiske angrep på enheten din, selv om sikkerheten er skjerpet på programvaresiden. Det er ikke dermed sagt at du ikke bør bruke tilpassede ROM-er, det er bare at det er andre bekymringer når det gjelder å bruke dem som ikke gjelder hvis oppstartslasteren din holdes låst. Hvis du er mer bekymret for programvaresiden av ting, er du fortsatt bedre med en tilpasset ROM som får hyppige sikkerhetsoppdateringer.

Men husk at vi snakket om forskjellen mellom ÅÅÅÅ-MM-01 og ÅÅÅÅ-MM-05 patcher? -05-oppdateringsnivået inneholder Linux-kjerne-patcher samt leverandør-patcher - patcher brukt på programvare med lukket kildekode. Dette betyr at tilpassede ROM-utviklere er prisgitt hvilken OEM de utvikler for, og om OEM-en gir ut oppdaterte blobs eller ikke. Dette er greit for enheter som fortsatt er oppdatert av produsenten, men for enheter som ikke er det, kan oppdateringene som brukes, bare brukes på Android-rammeverket og Linux-kjernen. Dette er grunnen til at LineageOS Trust Interface viser to sikkerhetsoppdateringsnivåer - det ene er plattform, det andre er leverandør. Selv om tilpassede ROM-er for enheter som ikke støttes, ikke fullt ut kan integrere alle de nyeste oppdateringene, kommer de til å være sikrere enn den eldre, utdaterte ROM-en.