Cum funcționează actualizările lunare ale corecțiilor de securitate Android

Google publică buletine de securitate lunare din august 2015. Aceste buletine de securitate conțin o listă de vulnerabilități de securitate dezvăluite care au fost remediate și care afectează cadrul Android, kernel-ul Linux și alte componente de furnizor cu sursă închisă. Fiecare vulnerabilitate din buletine a fost fie descoperită de Google, fie dezvăluite companiei. Fiecare vulnerabilitate listată are un număr CVE (Common Vulnerabilities and Exposures), împreună cu numărul asociat referințe, tipul de vulnerabilitate, o evaluare a gravității și versiunea AOSP afectată (dacă aplicabil). Dar, în ciuda procesului aparent simplist din spatele modului în care funcționează corecțiile de securitate Android, există de fapt o oarecum dus-întors complicat în culise, care permite telefonului dvs. să fie lunar sau (sperăm) aproape lunar petice.

Ce face de fapt un patch de securitate?

Poate ați observat că în fiecare lună există de fapt Două nivelurile patch-urilor de securitate. Formatul acestor patch-uri este fie AAAA-LL-01, fie AAAA-LL-05. În timp ce YYYY și MM reprezintă în mod evident anul și, respectiv, luna, „01” și „05” în mod confuz nu înseamnă de fapt ziua lunii în care acel nivel de corecție de securitate a fost lansat. În schimb, 01 și 05 sunt de fapt două niveluri diferite de corecție de securitate lansate în aceeași zi în fiecare lună - nivelul de corecție cu 01 la sfârșit conține remedieri pentru cadrul Android, dar nu patch-uri de furnizor sau corecții pentru nucleul Linux din amonte. Patch-urile furnizorului, așa cum am definit mai sus, se referă la remedieri ale componentelor cu sursă închisă, cum ar fi driverele pentru Wi-Fi și Bluetooth. Nivelul de corecție de securitate indicat prin -05 conține aceste corecții de furnizor, precum și patch-uri în nucleul Linux. Aruncă o privire la tabelul de mai jos, care poate ajuta la înțelegere.

Desigur, unii producători OEM pot alege să-și introducă propriile corecții și actualizări în actualizări de securitate. Majoritatea OEM-urilor au propria lor interpretare asupra Android, așa că are sens doar să aveți, de exemplu, o vulnerabilitate pe un telefon Samsung care nu există pe un Huawei. Mulți dintre acești OEM își publică și propriile buletine de securitate.

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

Cronologia unui patch de securitate de la Google pe telefonul dvs

Patch-urile de securitate au o cronologie de aproximativ 30 de zile, deși nu orice OEM poate beneficia de întreaga durată a acelei cronologie. Să aruncăm o privire la Patch de securitate mai 2019 de exemplu, și putem descompune întreaga cronologie din spatele creării acestui patch. Companii ca Esenţial reușesc să obțină actualizările de securitate in aceeasi zi ca Google Pixel, deci cum o fac? Răspunsul scurt și simplu este că sunt un Partener Android. Buletinul de securitate din mai 2019 a fost publicat pe 6 mai, atât Google Pixels, cât și Essential Phone primind actualizări aproape imediate.

Ce înseamnă să fii partener Android

Nu orice companie poate fi partener Android, deși, practic, fiecare OEM Android major este. Partenerii Android sunt companiile cărora li se acordă o licență de utilizare a mărcii Android în materiale de marketing. De asemenea, li se permite să livreze Serviciile Google Mobile (GMS - se referă la aproape toate serviciile Google), atâta timp cât îndeplinesc cerințele prezentate în Compatibility Definition Document (CDD) și treceți Compatibility Test Suite (CTS), Vendor Test Suite (VTS), Google Test Suite (GTS) și alte câteva teste. Există diferențe distincte în procesul de corecție de securitate pentru companiile care nu sunt un partener Android.

• Patch-urile de cadru Android sunt disponibile pentru ei după ce au fost îmbinate în AOSP cu 1-2 zile înainte de lansarea buletinului de securitate.
• Patch-urile kernel-ului Linux din amonte pot fi alese după ce sunt disponibile.
• Remedieri de la furnizorii de SoC pentru componentele cu sursă închisă sunt disponibile în funcție de acordurile cu furnizorul de SoC. Rețineți că, dacă furnizorul a acordat OEM acces la codul sursă al componentei (componentelor) cu sursă închisă, atunci OEM-ul poate rezolva singur problema (ele). Dacă OEM nu are acces la codul sursă, atunci trebuie să aștepte ca furnizorul să emită o remediere.

Dacă sunteți partener Android, veți avea imediat mult mai ușor. Partenerii Android sunt notificați cu privire la toate problemele legate de framework-ul Android și problemele legate de kernelul Linux cu cel puțin 30 de zile înainte ca buletinul să fie făcut public. Google oferă patch-uri pentru toate problemele pentru ca OEM-urile să le fuzioneze și să le testeze, deși corecțiile componente ale furnizorului depind de furnizor. Patch-uri pentru problemele cadrului Android dezvăluite în buletinul de securitate din mai 2019, de exemplu, au fost furnizate partenerilor Android cel puțin încă din 20 martie 2019*. Este o lot de prelungiri.

*Notă: Google poate și face adesea să actualizeze corecțiile pentru cel mai recent buletin de securitate până la lansarea publică. Aceste actualizări se pot întâmpla dacă au fost găsite noi vulnerabilități și erori, dacă Google decide să elimine anumite patch-uri din buletinul lunar din cauza spargerii componentelor critice, dacă Google actualizează un patch pentru a rezolva o eroare creată de versiunea anterioară a patch-ului și alte motive.

De ce trebuie să aștept atât de mult pentru a primi un patch de securitate pe telefon?

Deși este adevărat că partenerii Android (a se citi: toți producătorii OEM importanți) au primit corecții de securitate cu mult înaintea lor lansare, mulți sunt dureros de conștienți că, posibil, nu vor primi o actualizare de securitate luni de zile după aceasta eliberare. Acest lucru se datorează, în general, unuia dintre cele patru motive.

• Este posibil ca OEM-urile să fie nevoite să facă modificări tehnice importante pentru a găzdui un patch de securitate, deoarece acesta poate intra în conflict cu codul existent.
• Vânzătorul este lent în furnizarea codului sursă de actualizare pentru componentele cu sursă închisă.
• Certificarea operatorului poate dura timp.
• Este posibil ca companiile să nu dorească să lanseze o actualizare de securitate fără a lansa și o funcție în același timp.

Deși toate acestea sunt motive întemeiate pentru ca o companie să nu lanseze un patch de securitate, utilizatorului final nu îi pasă întotdeauna de niciunul dintre acestea. Desigur, nici utilizatorului final nu îi pasă întotdeauna de corecțiile de securitate, deși ar trebui. Inițiative precum Project Treble, Linux LTS extins, și Linia principală a proiectului ajută la eliminarea dificultăților tehnice legate de îmbinarea acestor corecții de securitate, dar nu este suficient pentru ca OEM-urile să se străduiască în mod constant să pună actualizări. Cu o imagine generică a kernelului, sau GKI, furnizorii de SoC și OEM-urile vor avea mai ușor să fuzioneze patch-urile de kernel Linux din amonte, deși probabil că nu vom vedea primele dispozitive cu GKI până anul viitor.

Dar o informație interesantă pe care majoritatea nu o știu este că OEM-urile majore trebuie sa furnizați „cel puțin patru actualizări de securitate” într-un an de la lansarea unui dispozitiv și, în general, 2 ani de actualizări. Google nu a confirmat acești termeni specifici, dar compania a confirmat că „a lucrat la integrarea corecțiilor de securitate în acordurile [lor] OEM”. În ceea ce privește dispozitivele Android Enterprise Recommended (AER), dispozitivele trebuie să primească actualizări de securitate în termen de 90 de zile de la lansare timp de 3 ani. Dispozitivele AER robuste sunt necesare pentru a obține 5 ani a actualizărilor de securitate. Dispozitivele Android One ar trebui să primească actualizări de securitate în fiecare lună timp de 3 ani.

Ce este într-un patch de securitate?

Un patch de securitate este doar o altă actualizare, deși, în general, mult mai mică, cu modificări ale cadrelor individuale și modulelor de sistem, mai degrabă decât îmbunătățiri sau modificări la nivel de sistem. În fiecare lună, Google oferă producătorilor OEM de dispozitive un fișier zip care conține corecții pentru toate versiunile majore de Android încă acceptate în prezent, împreună cu o suită de teste de securitate. Această suită de teste îi ajută pe OEM să identifice lacunele în corecțiile de securitate, pentru a se asigura că nu le lipsește nimic și că patch-urile au fost îmbinate în mod corespunzător. Pe măsură ce luna trece, Google poate face revizuiri minore, cum ar fi decizia că un anumit patch este opțional, mai ales dacă există probleme la implementarea acestuia.

Dar ROM-urile personalizate?

Dacă smartphone-ul tău nu primește multe actualizări de securitate, asta nu înseamnă neapărat că este mai bine să treci la un ROM personalizat. Deși este adevărat că veți primi actualizări de securitate pe care altfel nu le-ați fi primit, aceasta este doar jumătate din poveste. Deblocarea bootloader-ului vă lasă susceptibil la atacuri fizice asupra dispozitivului dvs., chiar dacă din partea software-ului, securitatea este întărită. Asta nu înseamnă că nu ar trebui să folosești ROM-uri personalizate, ci doar că există și alte preocupări atunci când vine vorba de utilizarea lor, care nu se aplică dacă bootloader-ul tău este ținut blocat. Dacă ești mai îngrijorat de partea software a lucrurilor, atunci îți este mai bine cu un ROM personalizat care primește patch-uri de securitate frecvente.

Dar țineți minte că am vorbit despre diferența dintre patch-urile AAAA-LL-01 și AAAA-LL-05? Nivelul de corecție -05 conține patch-uri pentru nucleul Linux, precum și patch-uri de furnizor - patch-uri aplicate software-ului cu sursă închisă. Aceasta înseamnă că dezvoltatorii de ROM personalizate sunt la cheremul oricărui OEM pentru care dezvoltă și dacă OEM lansează blob-uri actualizate sau nu. Acest lucru este în regulă pentru dispozitivele care sunt încă actualizate de producător, dar pentru dispozitivele care nu sunt, patch-urile aplicate pot fi aplicate numai cadrului Android și nucleului Linux. Acesta este motivul pentru care LineageOS Interfață de încredere arată două niveluri de corecție de securitate - unul fiind platformă, celălalt fiind furnizor. Chiar dacă ROM-urile personalizate pentru dispozitivele neacceptate nu pot integra pe deplin toate cele mai recente corecții, acestea vor fi mai sigure decât ROM-ul mai vechi și învechit.