Conform unui comit recent pe care l-am descoperit în Android Open Source Project, Google se pregătește pentru a distinge între nivelul de corecție de securitate a furnizorului și corecția de securitate Android Framework nivel. Acest lucru le permite OEM-urilor să mențină Android actualizat în timp ce așteaptă ca furnizorii de hardware să ofere remedieri.
Pentru o lungă perioadă de timp în istoria sa timpurie, Android a avut reputația de a fi mai puțin sigur decât iOS din cauza abordării aplicațiilor Apple „grădina cu pereți”. Dacă această reputație din trecut este meritată sau nu, nu este ceva în care ne vom scufunda, dar este clar că Google a făcut pași mari în securizarea Android împotriva vulnerabilităților. Compania nu numai că oferă noi funcții de securitate în cea mai recentă versiune de Android, Android P, dar oferă și „securitate la nivel de întreprindere„ în cele mai recente dispozitive, datorită unui modul de securitate hardware din Google Pixel 2/2 XL. Menținerea în siguranță a unui dispozitiv necesită, de asemenea, actualizări continue pentru a corecta toate cele mai recente amenințări, motiv pentru care Google a
Patch-uri lunare de securitate pentru Android - A Primer
Știm cu toții că patch-urile de securitate sunt importante, mai ales după ce un șir de vulnerabilități importante au fost făcute publice în a doua jumătate a anului trecut. The Vulnerabilitatea BlueBorne a atacat protocolul Bluetooth și a fost corectat în Patch-uri lunare septembrie 2017, KRACK vizează o slăbiciune în Wi-Fi WPA2 și a fost corectat decembrie 2017, iar vulnerabilitățile Spectre/Meltdown au fost în mare parte remediate cu Patch-uri din ianuarie 2018. Corectarea vulnerabilităților precum acestea necesită de obicei cooperarea cu un furnizor de hardware (cum ar fi Broadcom și Qualcomm), deoarece vulnerabilitatea se referă la o componentă hardware, cum ar fi cipul Wi-Fi sau Bluetooth sau CPU. Pe de altă parte, există probleme în sistemul de operare Android, cum ar fi aceasta atac de suprapunere mesaj toast care necesită doar o actualizare a cadrului Android pentru a remedia.
Ori de câte ori Google lansează un patch de securitate lunar, producătorii de dispozitive trebuie să repare TOATE vulnerabilitățile prezentate în buletinul de securitate al lunii respective, dacă doresc să spună că dispozitivul lor este securizat până la acel patch lunar nivel. În fiecare lună, există două niveluri de corecție de securitate pe care le poate îndeplini un dispozitiv: nivelul de corecție la data de 1 a lunii sau la data de 5 a lunii. Dacă un dispozitiv spune că rulează un nivel de patch din data de 1 a lunii (de ex. 1 aprilie, mai degrabă decât 5 aprilie), atunci asta înseamnă că versiunea conține toate corecțiile de cadru și furnizori din ultima lună, plus toate corecțiile de cadru din cel mai nou buletin de securitate. Pe de altă parte, dacă un dispozitiv spune că rulează un nivel de patch din data de 5 a lunii (5 aprilie, pt. exemplu), atunci asta înseamnă că conține toate corecțiile de cadru și furnizori de luna trecută și de luna aceasta buletin. Iată un tabel care exemplifica diferența de bază dintre nivelurile lunare ale patch-urilor:
Nivelul de corecție de securitate lunar |
1 Aprilie |
5 aprilie |
|---|---|---|
Conține patch-uri cadru de aprilie |
da |
da |
Conține patch-uri pentru furnizori din aprilie |
Nu |
da |
Conține patch-uri cadru de martie |
da |
da |
Conține patch-uri pentru furnizori din martie |
da |
da |
Probabil că sunteți familiarizat cu cât de dezastruoasă este situația corecțiilor de securitate în ecosistemul Android. Graficul de mai jos arată că Google și Essential oferă cele mai rapide actualizări lunare ale corecțiilor de securitate, în timp ce alte companii rămân în urmă. Pot dura luni până când un OEM aduce cele mai recente corecții pe un dispozitiv, cum ar fi modul în care OnePlus 5 și OnePlus 5T a primit recent Patch de securitate din aprilie când erau anterior pe plasturele din decembrie.
Starea corecției de securitate Android din februarie 2018. Sursă: @SecX13
Problema cu furnizarea de actualizări Android Security Patch nu este neapărat că OEM-urile sunt leneși, deoarece uneori poate fi în afara controlului lor. După cum am menționat anterior, actualizările lunare ale corecțiilor de securitate necesită adesea cooperarea unui hardware furnizor, care poate cauza întârzieri dacă furnizorul nu poate ține pasul cu corecția de securitate lunară buletine. Pentru a combate acest lucru, se pare că Google ar putea începe să separe nivelul de corecție de securitate Android Framework de nivelul de corecție a furnizorului. (și, eventual, încărcătorul de încărcare și nivelul kernelului), astfel încât, în viitor, OEM-urile să poată oferi securitate cadru pur Android actualizări.
Actualizări mai rapide ale corecțiilor de securitate Android pentru vulnerabilitățile cadrului?
Un nou comite a apărut în gerrit Android Open Source Project (AOSP) care sugerează un „patch de securitate al furnizorului prop" care ar fi definit în fișierele Android.mk ori de câte ori se află o nouă versiune pentru un dispozitiv creată. Această proprietate se va numi „ro.vendor.build.security_patch"și va fi analog cu"ro.build.version.security_patch" care există în prezent pe toate dispozitivele Android pentru a specifica nivelul lunar al corecției de securitate Android.
Această nouă proprietate ne va spune în schimb „VENDOR_SECURITY_PATCH" al dispozitivului, care poate sau nu să se potrivească cu nivelul de corecție de securitate Android Framework. De exemplu, un dispozitiv poate rula pe cele mai recente corecții cadru din aprilie 2018 împreună cu corecțiile furnizorului din februarie 2018. Făcând distincția între cele două niveluri de corecție de securitate, este posibil ca Google să intenționeze să permită OEM-urilor să livreze cele mai recente corecții de securitate pentru sistemul de operare Android, chiar dacă furnizorii nu au furnizat corecții actualizate pentru patch-ul lunar respectiv nivel.
Alternativ, Google poate afișa doar minimul dintre cele două niveluri de corecție (pe lângă nivelurile de încărcare de încărcare și de corecție a nucleului) pentru a arăta mai precis utilizatorului pe ce corecție de securitate se află dispozitivul său. Nu avem încă o confirmare cu privire la intenția din spatele acestui patch, dar sperăm să aflăm mai multe în curând.
Cel puțin, acest lucru va fi de ajutor pentru cei dintre noi Proiect TrebleImagini de sistem generice (GSI) și alte ROM-uri personalizate bazate pe AOSP, deoarece deseori ROM-urile personalizate oferă doar actualizări ale cadrului fără a patch-uri întregul furnizor; bootloader și corecții ale nucleului care sunt specificate într-un buletin de securitate lunar, astfel încât nepotrivirea provoacă confuzie în rândul utilizatorilor, deoarece aceștia cred că rulează cele mai recente corecții când, în realitate, dispozitivul lor este doar parțial corelat cu cea mai recentă securitate lunară buletin.