Har du nogensinde spekuleret på, hvordan de månedlige Android-sikkerhedspatch-opdateringer fungerer? Undre dig ikke mere, da vi kun har en primer, så du kan forstå hele processen.
Google har udgivet månedlige sikkerhedsbulletiner siden august 2015. Disse sikkerhedsbulletiner indeholder en liste over afslørede sikkerhedssårbarheder, som er blevet rettet, og som påvirker Android-frameworket, Linux-kernen og andre lukkede kildeleverandørkomponenter. Hver sårbarhed i bulletinerne blev enten opdaget af Google eller oplyst til virksomheden. Hver anført sårbarhed har et Common Vulnerabilities and Exposures (CVE)-nummer sammen med tilhørende referencer, typen af sårbarhed, en alvorlighedsvurdering og den berørte AOSP-version (hvis gældende). Men på trods af den tilsyneladende forsimplede proces bag, hvordan Android-sikkerhedspatches fungerer, er der faktisk noget kompliceret frem og tilbage bag kulisserne, der gør det muligt for din telefon at blive månedlig eller (forhåbentlig) næsten månedlig plastre.
Hvad gør egentlig en sikkerhedspatch?
Du har måske bemærket, at der faktisk er hver måned to niveauer af sikkerhedspatch. Formatet på disse patches er enten ÅÅÅÅ-MM-01 eller ÅÅÅÅ-MM-05. Mens YYYY og MM tydeligvis repræsenterer henholdsvis året og måneden, betyder "01" og "05" til forveksling ikke den dag i måneden, hvor sikkerhedsopdateringsniveauet blev frigivet. I stedet er 01 og 05 faktisk to forskellige sikkerhedspatch-niveauer, der udgives samme dag hver måned - patch-niveauet med 01 i slutningen indeholder rettelser til Android-rammerne, men ikke leverandørpatches eller upstream Linux-kernepatches. Leverandørpatches, som vi definerede ovenfor, henviser til rettelser til lukkede kildekomponenter såsom drivere til Wi-Fi og Bluetooth. Sikkerhedspatch-niveauet angivet med -05 indeholder disse leverandørpatches såvel som patches i Linux-kernen. Tag et kig på tabellen nedenfor, som kan hjælpe dig med at forstå.
Månedligt sikkerhedspatch-niveau |
2019-04-01 |
2019-04-05 |
---|---|---|
Indeholder April Framework Patches |
Ja |
Ja |
Indeholder April Vendor + Kernel Patches |
Ingen |
Ja |
Indeholder March Framework Patches |
Ja |
Ja |
Indeholder March Vendor + Kernel Patches |
Ja |
Ja |
Selvfølgelig kan nogle OEM'er også vælge at rulle deres egne patches og opdateringer til sikkerhedsopdateringer. De fleste OEM'er har deres eget bud på Android, så det giver kun mening, at du for eksempel kan have en sårbarhed på en Samsung-telefon, som ikke findes på en Huawei. Mange af disse OEM'er udgiver også deres egne sikkerhedsbulletiner.
- Google Pixel
- Huawei
- LG
- Motorola
- HMD Global
- Samsung
Tidslinjen for en sikkerhedsopdatering fra Google til din telefon
Sikkerhedsrettelser har en tidslinje, der groft strækker sig over omkring 30 dage, selvom ikke alle OEM kan benytte hele tidslinjens længde. Lad os tage et kig på maj 2019 sikkerhedsrettelse for eksempel, og vi kan nedbryde hele tidslinjen bag oprettelsen af denne patch. Virksomheder kan lide Vigtig formår at få deres sikkerhedsopdateringer ud samme dag som Google Pixel, så hvordan gør de det? Det korte og enkle svar er, at de er en Android partner. Sikkerhedsbulletin fra maj 2019 udkom den 6. maj, hvor både Google Pixels og Essential Phone får næsten øjeblikkelige opdateringer.
Hvad det vil sige at være Android-partner
Ikke en hvilken som helst virksomhed kan være en Android-partner, selvom stort set alle større Android OEM er det. Android-partnere er de virksomheder, der får licens til at bruge Android-brandingen i markedsføringsmateriale. De har også tilladelse til at sende Google Mobile Services (GMS - refererer til stort set alle Google-tjenester), så længe de opfylder kravene i Compatibility Definition Document (CDD) og bestå Compatibility Test Suite (CTS), Vendor Test Suite (VTS), Google Test Suite (GTS) og et par andre tests. Der er tydelige forskelle i sikkerhedsopdateringsprocessen for virksomheder, der er det ikke en Android-partner.
- Android framework patches er tilgængelige for dem efter at være blevet flettet ind i AOSP 1-2 dage før sikkerhedsbulletinen udgives.
- Opstrøms Linux-kerne-patches kan cherry-plukkes, når de er tilgængelige.
- Rettelser fra SoC-leverandører til lukkede kildekomponenter er tilgængelige afhængigt af aftaler med SoC-leverandøren. Bemærk, at hvis leverandøren har givet OEM-en adgang til kildekoden for de lukkede kildekomponenter, så kan OEM selv løse problemet. Hvis OEM ikke har adgang til kildekoden, skal de vente på, at leverandøren udsteder en rettelse.
Hvis du er Android Partner, har du det straks meget nemmere. Android-partnere får besked om alle Android-framework-problemer og Linux-kerneproblemer mindst 30 dage før bulletinen offentliggøres. Google leverer patches til alle problemer, som OEM'er kan flette og teste, selvom leverandørkomponentpatches er afhængige af leverandøren. Patches til Android-rammeproblemerne, der blev afsløret i sikkerhedsbulletinen fra maj 2019, blev for eksempel leveret til Android-partnere mindst så tidligt som den 20. marts 2019*. Det er en masse af ekstra tid.
*Bemærk: Google kan, og gør det ofte, opdatere programrettelserne til den seneste sikkerhedsbulletin hele vejen indtil den offentlige udgivelse. Disse opdateringer kan ske, hvis der er fundet nye sårbarheder og fejl, hvis Google beslutter at fjerne visse patches fra den månedlige bulletin på grund af at det bryder kritiske komponenter, hvis Google opdaterer en patch for at løse en fejl oprettet af den tidligere version af patchen, og andre grunde.
Hvorfor skal jeg vente så længe på at modtage en sikkerhedspatch på min telefon?
Selvom det er rigtigt, at Android-partnere (læs: alle større OEM'er) modtog sikkerhedsrettelser i god tid før deres udgivelse, er mange smerteligt klar over, at de muligvis ikke vil modtage en sikkerhedsopdatering i flere måneder efter dens frigøre. Dette skyldes generelt en af fire årsager.
- OEM'er kan være nødt til at foretage omfattende tekniske ændringer for at imødekomme en sikkerhedsopdatering, da den kan være i konflikt med eksisterende kode.
- Leverandøren er langsom til at levere opdateringskildekode til lukkede kildekomponenter.
- Transportørcertificering kan tage tid.
- Virksomheder kan være uvillige til at frigive en sikkerhedsopdatering uden også at frigive en funktion på samme tid.
Selvom alle disse er gyldige grunde til, at en virksomhed ikke frigiver en sikkerhedspatch, er slutbrugeren ikke altid ligeglad med nogen af dem. Ganske vist er slutbrugeren heller ikke altid ligeglad med sikkerhedsrettelser, selvom de burde. Initiativer som Project Treble, udvidet Linux LTS, og Projekt Hovedlinje hjælper med at eliminere de tekniske vanskeligheder ved at fusionere disse sikkerhedsrettelser, men det er ikke nok til at få OEM'er til konsekvent at stræbe efter at udgive opdateringer. Med et generisk kernebillede eller GKI vil SoC-leverandører og OEM'er have lettere ved at fusionere upstream Linux-kernepatches, selvom vi sandsynligvis ikke vil se de første enheder med GKI før næste år.
Men en interessant oplysning, som de fleste ikke ved, er, at de store OEM'er skal levere "mindst fire sikkerhedsopdateringer" inden for et år efter en enheds lancering og 2 års opdateringer i alt. Google har ikke bekræftet disse specifikke vilkår, men virksomheden bekræftede, at de "arbejdede på at indbygge sikkerhedspatching i [deres] OEM-aftaler". Hvad angår Android Enterprise Recommended (AER)-enheder, skal enheder få sikkerhedsopdateringer inden for 90 dage efter udgivelsen i 3 år. Robuste AER-enheder er påkrævet for at få 5 år af sikkerhedsopdateringer. Android One-enheder formodes at få sikkerhedsopdateringer hver måned i 3 år.
Hvad er der i en sikkerhedspatch?
En sikkerhedspatch er blot endnu en opdatering, dog generelt meget mindre med ændringer til individuelle rammer og systemmoduler frem for systemomfattende forbedringer eller ændringer. Hver måned forsyner Google OEM'er med enheder med en zip-fil, der indeholder patches til alle større Android-versioner, der i øjeblikket stadig understøttes, sammen med en sikkerhedstestpakke. Denne testpakke hjælper OEM'er med at fange huller i sikkerhedsrettelser, for at sikre, at de ikke går glip af noget og at lapperne blev flettet passende sammen. Som måneden går, kan Google foretage mindre revisioner, såsom at beslutte, at en specifik patch er valgfri, specielt hvis der er problemer med at implementere den.
Hvad med brugerdefinerede ROM'er?
Hvis din smartphone ikke får mange sikkerhedsopdateringer, betyder det ikke nødvendigvis, at du er bedre til at skifte til en brugerdefineret ROM. Selvom det er sandt, at du vil få sikkerhedsopdateringer, som du ellers ikke ville have fået, er det kun halvdelen af historien. Oplåsning af din bootloader efterlader dig modtagelig for fysiske angreb på din enhed, selvom sikkerheden på softwaresiden er hærdet. Det betyder ikke, at du ikke skal bruge brugerdefinerede ROM'er, det er bare, at der er andre bekymringer, når det kommer til at bruge dem, som ikke gælder, hvis din bootloader holdes låst. Hvis du er mere bekymret for software-siden af tingene, så er du stadig bedre stillet med en tilpasset ROM, der ofte får sikkerhedsrettelser.
Men husk, at vi talte om forskellen mellem ÅÅÅÅ-MM-01 og ÅÅÅÅ-MM-05 plastre? -05-patch-niveauet indeholder Linux-kerne-patches såvel som leverandør-patches - patches, der anvendes til closed source-software. Dette betyder, at brugerdefinerede ROM-udviklere er prisgivet den OEM, de udvikler til, og om OEM'en udgiver opdaterede blobs eller ej. Dette er fint for enheder, der stadig er opdateret af producenten, men for enheder, der ikke er det, kan de anvendte patches kun anvendes til Android-frameworket og Linux-kernen. Det er derfor LineageOS' Tillidsgrænseflade viser to sikkerhedspatch-niveauer - det ene er platform, det andet er leverandør. Selvom brugerdefinerede ROM'er til ikke-understøttede enheder ikke fuldt ud kan integrere alle de nyeste patches, vil de være mere sikre end den ældre, forældede ROM.