Come funzionano le patch di sicurezza mensili di Android

È dall'agosto del 2015 che Google ci fornisce mensilmente delle patch di sicurezza per Android. Ma come funzionano esattamente queste patch? Qual è l'iter che permette di passare dal codice fornito di Google al firmware rilasciato via OTA dai vari produttori? Cerchiamo di dare una risposta.

Ogni vulnerabilità che è stata rimossa ha un suo numero identificativo CVE (Common Vulnerabilities and Exposures), i riferimenti associati, il tipo, il grado di severità e la versione AOSP colpita (se esiste). L'unione di tutti questi fix va a creare la patch di sicurezza mensile.

I più attenti avranno notato come ogni mesi vengono rilasciate due diverse patch di sicurezza. Il loro formato è AAAA-MM-01 e AAAA-MM-05. Se AAAA e MM identificano, rispettivamente, anno e mese di rilascio, le ultime due cifre potrebbero far fare confusione: non indicano il giorno di rilascio, ma il "grado di sicurezza":

• AAAA-MM-01 contiene i fix mensili al framework di Android ma non le patch di sicurezza dei fornitori (vendor patches) e le patch al kernel di Linux.
• AAAA-MM-05 contiene il pacchetto completo.

Queste due patch sono rilasciate lo stesso giorno del mese e si basano sulle patch "05" del mese precedente (per chiarezza vi consigliamo di rifarvi alla tabella qui sotto nella quale è indicato, come esempio, la patch di sicurezza di aprile 2019).

Le "patch di sicurezza dei fornitori" si riferiscono al codice close-source relativo ai componenti fisici, come possono essere i driver per il Wi-Fi o per il Bluetooth.

È importante sottolineare come ogni specifico produttore (OEM) possa modificare le patch di sicurezza mensili inserendo modifiche specifiche relative al singolo modello. Questo non dovrebbe stupire: alcune vulnerabilità potrebbero colpire Samsung ma non Motorola (per fare un esempio). Fortunatamente alcuni produttori pubblicano la lista delle modifiche specifiche per ogni modello:

• Google (Pixel)
• HMD Global (Nokia)
• Huawei
• LG
• Motorola
• Samsung

Sebbene Google rilasci le patch di sicurezza in un giorno (non meglio precisato) del mese, alcuni OEM riescono a fornire l'aggiornamento per i propri dispositivi prima degli altri. Com'è possibile? Certo, alcuni devono inserire le proprie modifiche all'interno del firmware (si veda il punto precedente), ma c'è anche un altro dettaglio rilevante: alcuni OEM sono Android partner.

Come si diventa Android partner? Quali sono i vantaggi?

Chi sono questi Android partner? Sono aziende che hanno ottenuto la licenza per utilizzare il brand Android nel materiale per il marketing ma, soprattutto, possono inserire i Google Mobile Services (GMS) all'interno dei propri prodotti.

Ovviamente tutti i principali OEM sono Android partner, ma non è così semplice diventarlo: è necessario rispettare determinati requisiti in termini di Compatibility Definition Document (CDD) e superare alcuni test, tra i quali Compatibility Test Suite (CTS), Vendor Test Suite (VTS), Google Test Suite (GTS).

In tutto questo c'è un enorme vantaggio temporale: gli Android partner non solo ricevono notifiche riguardanti i problemi al framework e al kernel Linux almeno 30 giorni prima del rilascio del changelog, ma ricevono anche da Google le patch per questi problemi in anticipo in modo tale che possano testarle e unirle ai firmware (all'interno di un bel file zip). Per fare un esempio, i problemi risolti nella patch di maggio 2019 sono stati comunicati il 20 marzo 2019. Quasi un mese e mezzo prima.

Questo non significa che il changelog è fissato 30 giorni prima del rilascio: Google ha la facoltà di cambiarlo in corso d'opera nel caso sia necessario sistemare qualche bug o vulnerabilità pericolosa.

Come cambiano le tempistiche per un'azienda NON Android partner?

Se un'azienda non si trova nell'Olimpo dei privilegiati, il processo di rilascio di una patch di sicurezza viene inevitabilmente allungato a causa di alcuni dettagli non trascurabili che vengono risparmiati agli Android partner:

• Le patch per il framework di Android sono disponibili dopo essere state unite nell'AOSP, solitamente 1-2 giorni dopo il rilascio del changelog di sicurezza.
• Le patch al kernel Linux vengono selezionate solamente dopo il rilascio.
• Le patch relative ai fornitori dipendono unicamente dall'accordo tra OEM e azienda produttrice. Questo significa che l'OEM può creare i propri fix se ha accesso al codice sorgente o deve attendere la patch dal fornitore.

Alcuni Android partner non forniscono rapidamente le patch di sicurezza mensili. Perché? I problemi possono essere molteplici:

• Gli OEM devono apportare significativi cambiamenti al codice a causa di qualche incompatibilità
• I fornitori non forniscono le patch dei componenti rapidamente
• La certificazione da parte degli operatori (per i modelli brandizzati) può richiedere tempo
• Alcune aziende potrebbero non voler rilasciare patch di sicurezza senza l'aggiunta di nuove funzionalità (per questioni d'immagine e di gestione delle risorse interne)

Per affrontare tutti questi problemi, nel tempo Google ha cercato di rimuovere queste problematiche (si pensi a Project Treble o a Project Mainline), e alcune di esse hanno avuto un impatto rilevante sulla diffusione delle patch.

Tuttavia, è sotto gli occhi di tutti come questo approccio, ad oggi, non è sufficiente a fornire tempestivamente le patch di sicurezza a tutti.

Non avete ricevuto una patch di sicurezza? Conviene, per questo motivo, passare a una ROM modificata contenente le ultime patch di sicurezza? Non è detto. Certo, alcuni fix vengono sistemati con le patch non fornite dall'OEM, ma lo sblocco del bootloader lascia il dispositivo più vulnerabile agli attacchi esterni.

Questo significa che non è detto che l'installazione di una ROM custom sia la scelta più sensata dal punto di vista della sicurezza. Per di più, con una ROM custom vi portate a casa solo le migliorie contenute nelle patch AAAA-MM-01, lasciando fuori le patch dei fornitori. Insomma, la parte relativa ai componenti interni è comunque nelle mani degli OEM.

Lo sapevate che i maggiori OEM devono fornire "almeno 4 patch di sicurezza" all'interno del primo anno di vita di un dispositivo e 2 anni di aggiornamenti? Non sono dati specificati da Google, ma l'azienda ha specificato che ha "lavorato sul fornire le patch di sicurezza all'interno degli accordi con gli OEM".

Per di più:

• i dispositivi Android Enterprise Recommended (AER) devono ricevere patch di sicurezza entro 90 giorni dal rilascio per 3 anni
• i dispositivi rugged AER devono ricevere aggiornamenti di sicurezza per 5 anni
• i dispositivi Android One dovrebbero ricevere le patch di sicurezza ogni mese per 3 anni