Hoe maandelijkse Android-beveiligingspatchupdates werken

Google publiceert sinds augustus 2015 maandelijkse beveiligingsbulletins. Deze beveiligingsbulletins bevatten een lijst met bekendgemaakte beveiligingsproblemen die zijn opgelost en die van invloed zijn op het Android-framework, de Linux-kernel en andere componenten van closed-sourceleveranciers. Elke kwetsbaarheid in de bulletins werd ontdekt door Google of bekend gemaakt aan het bedrijf. Elke vermelde kwetsbaarheid heeft een Common Vulnerabilities and Exposures (CVE)-nummer, samen met de bijbehorende referenties, het type kwetsbaarheid, een beoordeling van de ernst en de betrokken AOSP-versie (indien van toepassing). Maar ondanks het schijnbaar simplistische proces achter de manier waarop Android-beveiligingspatches werken, is er eigenlijk een enigszins ingewikkeld heen en weer achter de schermen waardoor uw telefoon maandelijks of (hopelijk) bijna maandelijks wordt ontvangen pleisters.

Wat is eigenlijk een beveiligingspatch?

Het is je misschien opgevallen dat er elke maand wel een aantal zijn twee beveiligingspatchniveaus. Het formaat van deze patches is JJJJ-MM-01 of JJJJ-MM-05. Hoewel JJJJ en MM duidelijk respectievelijk het jaar en de maand vertegenwoordigen, duiden de "01" en "05" verwarrend genoeg niet op de dag van de maand waarin dat beveiligingspatchniveau werd uitgebracht. In plaats daarvan zijn de 01 en 05 eigenlijk twee verschillende beveiligingspatchniveaus die elke maand op dezelfde dag worden uitgebracht - het patchniveau met 01 aan het einde bevat oplossingen voor het Android-framework, maar niet leverancierspatches of upstream Linux-kernelpatches. Leverancierspatches, zoals we hierboven hebben gedefinieerd, verwijzen naar oplossingen voor closed-sourcecomponenten zoals stuurprogramma's voor Wi-Fi en Bluetooth. Het beveiligingspatchniveau dat wordt aangegeven met -05 bevat zowel deze leverancierspatches als patches in de Linux-kernel. Kijk eens naar de onderstaande tabel, die kan helpen bij het begrijpen.

Natuurlijk kunnen sommige OEM's ervoor kiezen om hun eigen patches en updates ook in beveiligingsupdates te verwerken. De meeste OEM's hebben hun eigen kijk op Android, dus het is alleen maar logisch dat je bijvoorbeeld een kwetsbaarheid hebt op een Samsung-telefoon die niet bestaat op een Huawei. Veel van deze OEM's publiceren ook hun eigen beveiligingsbulletins.

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

De tijdlijn van een beveiligingspatch van Google naar je telefoon

Beveiligingspatches hebben een tijdlijn van ongeveer 30 dagen, hoewel niet elke OEM gebruik kan maken van de volledige lengte van die tijdlijn. Laten we eens kijken naar de Beveiligingspatch van mei 2019 en we kunnen bijvoorbeeld de hele tijdlijn achter de creatie van deze patch uitsplitsen. Bedrijven houden van Essentieel erin slagen hun beveiligingsupdates uit te brengen op dezelfde dag als de Google Pixel, dus hoe doen ze het? Het korte en simpele antwoord is dat ze een Android-partner. Het beveiligingsbulletin van mei 2019 werd op 6 mei gepubliceerd, waarbij zowel de Google Pixels als de Essential Phone vrijwel onmiddellijke updates krijgen.

Wat het betekent om een ​​Android-partner te zijn

Niet zomaar elk bedrijf kan een Android-partner zijn, hoewel vrijwel elke grote Android-OEM dat wel is. Android Partners zijn de bedrijven die een licentie hebben gekregen om de Android-branding in marketingmateriaal te gebruiken. Ze mogen ook Google Mobile Services (GMS - verwijst naar vrijwel alle Google-services) leveren, zolang ze voldoen aan de vereisten die zijn uiteengezet in de Compatibiliteitsdefinitiedocument (CDD) en slagen voor de Compatibility Test Suite (CTS), Vendor Test Suite (VTS), Google Test Suite (GTS) en een paar andere tests. Er zijn duidelijke verschillen in het beveiligingspatchproces voor bedrijven die dat doen zijn niet een Android-partner.

• Android-frameworkpatches zijn voor hen beschikbaar nadat ze 1-2 dagen vóór het beveiligingsbulletin zijn samengevoegd in AOSP.
• Upstream Linux-kernelpatches kunnen worden uitgekozen zodra ze beschikbaar zijn.
• Er zijn oplossingen van SoC-leveranciers voor closed-sourcecomponenten beschikbaar, afhankelijk van de overeenkomsten met de SoC-leverancier. Houd er rekening mee dat als de leverancier de OEM toegang heeft gegeven tot de broncode van de closed-source component(en), de OEM de problemen zelf kan oplossen. Als de OEM geen toegang heeft tot de broncode, moet hij wachten tot de leverancier met een oplossing komt.

Als u Android Partner bent, heeft u het meteen een stuk eenvoudiger. Android-partners worden minimaal 30 dagen voordat het bulletin openbaar wordt gemaakt, op de hoogte gesteld van alle problemen met het Android-framework en de Linux-kernel. Google biedt patches voor alle problemen die OEM's kunnen samenvoegen en testen, hoewel patches voor leverancierscomponenten afhankelijk zijn van de leverancier. Patches voor de problemen met het Android-framework die in het beveiligingsbulletin van mei 2019 zijn bekendgemaakt, zijn bijvoorbeeld al op 20 maart 2019 aan Android-partners verstrekt*. Dat is een kavel van extra tijd.

*Opmerking: Google kan de patches voor het nieuwste beveiligingsbulletin updaten, en doet dit vaak, tot aan de publieke release. Deze updates kunnen plaatsvinden als er nieuwe kwetsbaarheden en bugs zijn gevonden, als Google besluit bepaalde patches uit het maandbulletin te verwijderen doordat kritieke componenten kapot gaan, als Google een patch bijwerkt om een ​​bug op te lossen die door de vorige versie van de patch is gemaakt, en andere redenen.

Waarom moet ik zo lang wachten voordat ik een beveiligingspatch op mijn telefoon ontvang?

Hoewel het waar is dat Android-partners (lees: alle grote OEM's) ruim vóór hun beveiligingspatches hebben ontvangen release, zijn velen zich er pijnlijk van bewust dat ze mogelijk pas maanden later een beveiligingsupdate zullen ontvangen uitgave. Dit heeft meestal te maken met een van de vier redenen.

• OEM's moeten mogelijk zware technische wijzigingen aanbrengen om een ​​beveiligingspatch mogelijk te maken, omdat deze in conflict kan komen met bestaande code.
• De leverancier is traag in het leveren van bijgewerkte broncode voor closed-sourcecomponenten.
• Certificering van vervoerders kan enige tijd duren.
• Bedrijven zijn mogelijk niet bereid een beveiligingsupdate uit te brengen zonder tegelijkertijd ook een functie vrij te geven.

Hoewel dit allemaal geldige redenen zijn voor een bedrijf om geen beveiligingspatch uit te brengen, maakt de eindgebruiker zich daar niet altijd druk om. Toegegeven, de eindgebruiker geeft ook niet altijd om beveiligingspatches, hoewel dat wel zou moeten. Initiatieven als Project Treble, uitgebreide Linux LTS, En Project Hoofdlijn helpen de technische problemen bij het samenvoegen van deze beveiligingspatches weg te nemen, maar het is niet genoeg om OEM's er consequent naar te laten streven updates uit te brengen. Met een Generic Kernel Image, of GKI, zullen SoC-leveranciers en OEM's het gemakkelijker hebben om upstream Linux-kernelpatches samen te voegen, hoewel we de eerste apparaten met GKI waarschijnlijk pas volgend jaar zullen zien.

Maar een interessant stukje informatie dat de meesten niet weten, is dat grote OEM's moeten binnen een jaar na de lancering van een apparaat "minstens vier beveiligingsupdates" bieden, en in totaal twee jaar aan updates. Google heeft deze specifieke voorwaarden niet bevestigd, maar het bedrijf heeft wel bevestigd dat ze "werkten aan het inbouwen van beveiligingspatches in [hun] OEM-overeenkomsten". Wat betreft Android Enterprise Aanbevolen (AER)-apparaten: apparaten moeten gedurende 3 jaar binnen 90 dagen na release beveiligingsupdates ontvangen. Hiervoor zijn robuuste AER-apparaten vereist 5 jaar van beveiligingsupdates. Android One-apparaten moeten drie jaar lang elke maand beveiligingsupdates krijgen.

Wat zit er in een beveiligingspatch?

Een beveiligingspatch is gewoon weer een update, maar over het algemeen een stuk kleiner, met wijzigingen aan individuele raamwerken en systeemmodules in plaats van systeembrede verbeteringen of wijzigingen. Elke maand voorziet Google OEM's van apparaten van een zip-bestand met patches voor alle belangrijke Android-versies die momenteel nog worden ondersteund, samen met een beveiligingstestpakket. Deze testsuite helpt OEM's gaten in beveiligingspatches op te sporen, om ervoor te zorgen dat ze niets missen en dat de patches op de juiste manier zijn samengevoegd. Naarmate de maand vordert, kan Google kleine herzieningen doorvoeren, zoals het besluit dat een specifieke patch optioneel is, vooral als er problemen zijn bij de implementatie ervan.

Hoe zit het met aangepaste ROM's?

Als uw smartphone niet veel beveiligingsupdates krijgt, betekent dat niet noodzakelijkerwijs dat u beter kunt overstappen naar een aangepast ROM. Hoewel het waar is dat u beveiligingsupdates krijgt die u anders niet zou hebben gekregen, is dat slechts de helft van het verhaal. Als u uw bootloader ontgrendelt, bent u vatbaar voor fysieke aanvallen op uw apparaat, zelfs als de beveiliging aan de softwarekant is verscherpt. Dat wil niet zeggen dat je geen aangepaste ROM's moet gebruiken, het is alleen dat er andere problemen zijn als het gaat om het gebruik ervan, die niet van toepassing zijn als je bootloader vergrendeld blijft. Als je je meer zorgen maakt over de softwarekant, ben je nog steeds beter af met een aangepast ROM dat regelmatig beveiligingspatches krijgt.

Maar weet je nog dat we het hadden over het verschil tussen de patches JJJJ-MM-01 en JJJJ-MM-05? Het -05 patchniveau bevat zowel Linux-kernelpatches als leverancierspatches - patches die worden toegepast op closed-source software. Dit betekent dat aangepaste ROM-ontwikkelaars overgeleverd zijn aan de OEM waarvoor ze ontwikkelen, en of de OEM bijgewerkte blobs vrijgeeft of niet. Dit is prima voor apparaten die nog steeds worden bijgewerkt door de fabrikant, maar voor apparaten die dat niet zijn, kunnen de toegepaste patches alleen worden toegepast op het Android-framework en de Linux-kernel. Dit is de reden waarom LineageOS Vertrouwensinterface toont twee beveiligingspatchniveaus: het ene is een platform en het andere is een leverancier. Hoewel aangepaste ROM's voor niet-ondersteunde apparaten niet alle nieuwste patches volledig kunnen integreren, zullen ze veiliger zijn dan de oudere, verouderde ROM.