Hogyan működnek a havi Android biztonsági javítások frissítései

A Google 2015 augusztusa óta havi biztonsági közleményeket tesz közzé. Ezek a biztonsági közlemények a kijavított, nyilvánosságra hozott biztonsági rések listáját tartalmazzák, amelyek az Android keretrendszert, a Linux kernelt és más zárt forráskódú gyártói összetevőket érintik. A közlemények minden sebezhetőségét vagy a Google fedezte fel, vagy közölték a társasággal. Minden felsorolt ​​sebezhetőséghez tartozik egy általános sebezhetőség és kitettség (CVE) szám, valamint a kapcsolódó hivatkozásokat, a sebezhetőség típusát, súlyossági értékelést és az érintett AOSP-verziót (ha alkalmazható). De annak ellenére, hogy az Android biztonsági javítások működése mögött a látszólag leegyszerűsített folyamat áll, valójában van egy bizonyos mértékig bonyolult oda-vissza a színfalak mögött, amely lehetővé teszi, hogy a telefon havonta vagy (remélhetőleg) közel havi foltok.

Mitől lesz valójában egy biztonsági javítás?

Talán észrevetted, hogy minden hónapban vannak kettő biztonsági javítások szintjeit. Ezeknek a javításoknak a formátuma ÉÉÉÉ-HH-01 vagy ÉÉÉÉ-HH-05. Míg az ÉÉÉÉ és HH nyilvánvalóan az évet és a hónapot jelöli, a "01" és a "05" megtévesztő módon valójában nem jelenti annak a hónapnak a napját, amikor a biztonsági javítás szintje megjelent. Ehelyett a 01 és 05 valójában két különböző biztonsági javítási szint, amelyet minden hónap ugyanazon a napján adnak ki – a 01-es javítási szint a végén az Android keretrendszer javításait tartalmazza, de nem gyártói javítások vagy upstream Linux kernel javítások. A gyártói javítások, amint azt fentebb definiáltuk, a zárt forráskódú összetevők, például a Wi-Fi és a Bluetooth illesztőprogramjainak javításaira vonatkoznak. A -05 jelű biztonsági javítási szint tartalmazza ezeket a gyártói javításokat, valamint a Linux kernel javításait. Vessen egy pillantást az alábbi táblázatra, amely segíthet a megértésében.

Természetesen egyes OEM-ek dönthetnek úgy, hogy saját javításaikat és frissítéseiket is biztonsági frissítésekké teszik. A legtöbb OEM-nek megvan a saját véleménye az Androidról, így csak akkor van értelme, ha például egy Samsung telefonon van egy olyan sebezhetőség, amely a Huawei esetében nem létezik. Ezen OEM-ek közül sok saját biztonsági közleményt is közzétesz.

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

A Google-tól a telefonra küldött biztonsági javítás idővonala

A biztonsági javítások idővonala nagyjából 30 napot ölel fel, bár nem minden OEM tudja kihasználni az idővonal teljes hosszát. Vessünk egy pillantást a 2019 májusi biztonsági javítás például, és lebonthatjuk a javítás létrehozása mögötti teljes idővonalat. Cégek, mint Alapvető sikerül kivenni a biztonsági frissítéseiket ugyanazon a napon mint a Google Pixel, akkor hogyan csinálják? A rövid és egyszerű válasz az, hogy ők egy Android partner. A 2019. májusi biztonsági közlemény május 6-án jelent meg, a Google Pixels és az Essential Phone is szinte azonnali frissítéseket kap.

Mit jelent Android-partnernek lenni?

Nem akármelyik vállalat lehet Android-partner, bár alapvetően minden nagyobb Android OEM-gyártó az. Az Android Partnerek azok a vállalatok, amelyek engedélyt kaptak az Android márkajelzés marketinganyagokban való használatára. A Google Mobile Services (GMS – nagyjából az összes Google szolgáltatásra utal) szállítása is engedélyezett, amennyiben megfelelnek a Compatibility Definition Document (CDD), és teljesíti a Compatibility Test Suite (CTS), Vendor Test Suite (VTS), Google Test Suite (GTS) és néhány egyéb tesztet. Jelentős különbségek vannak a biztonsági javítási folyamatban azoknál a cégeknél, amelyek nem azok egy Android partner.

• Az Android keretrendszer javításai a biztonsági közlemény megjelenése előtt 1-2 nappal az AOSP-be való egyesítése után érhetők el.
• Az upstream Linux kernel-javítások könnyen kiválaszthatók, amint rendelkezésre állnak.
• A zárt forráskódú összetevőkre vonatkozó SoC-szállítók javításai az SoC-szállítóval kötött megállapodásoktól függően érhetők el. Vegye figyelembe, hogy ha a szállító hozzáférést adott az OEM-nek a zárt forráskódú összetevő(k) forráskódjához, akkor az OEM maga is kijavíthatja a problémát. Ha az OEM nem fér hozzá a forráskódhoz, akkor meg kell várnia, amíg a szállító kiadja a javítást.

Ha Ön Android-partner, akkor azonnal sokkal könnyebb lesz. Az Android-partnerek a közlemény nyilvánosságra hozatala előtt legalább 30 nappal értesítést kapnak minden Android-kernel-problémáról és Linux-kernel-problémáról. A Google minden problémára javításokat biztosít az OEM-ek számára, hogy egyesítsék és teszteljék, bár a szállítói összetevők javításai a gyártótól függenek. A 2019. májusi biztonsági közleményben közzétett Android-keretrendszer-problémák javításait például az Android-partnerek már legalább 2019. március 20-án* megkapták. Az egy sok többletidőből.

*Megjegyzés: A Google frissítheti – és gyakran teszi – a legújabb biztonsági közlemény javításait egészen a nyilvános megjelenésig. Ezek a frissítések akkor történhetnek meg, ha új sebezhetőségeket és hibákat találnak, ha a Google úgy dönt, hogy eltávolít bizonyos javításokat a havi közleményből. a kritikus összetevők feltörése miatt, ha a Google frissít egy javítást a javítás előző verziója által okozott hiba megoldása érdekében, és egyéb okokból.

Miért kell olyan sokáig várnom, hogy megkapjam a biztonsági javítást a telefonomra?

Bár igaz, hogy az Android Partnerek (értsd: minden nagyobb OEM) megkapták a biztonsági javításokat jóval az előtt, kiadás, sokan fájdalmasan tudatában vannak annak, hogy valószínűleg hónapokig nem kapnak biztonsági frissítést kiadás. Ez általában a négy ok egyikére vezethető vissza.

• Előfordulhat, hogy az OEM-eknek komoly technikai változtatásokat kell végrehajtaniuk a biztonsági javítások elhelyezése érdekében, mivel az ütközhet a meglévő kóddal.
• A szállító lassan frissíti a forráskódot a zárt forráskódú összetevőkhöz.
• A szolgáltató tanúsítása időbe telhet.
• Előfordulhat, hogy a vállalatok nem hajlandók kiadni egy biztonsági frissítést anélkül, hogy egyidejűleg kiadnának egy szolgáltatást is.

Noha ezek mindegyike megalapozott indok arra, hogy egy vállalkozás ne adjon ki biztonsági javítást, a végfelhasználót ezek egyike sem mindig érdekli. Igaz, a végfelhasználót sem mindig érdeklik a biztonsági javítások, pedig kellene. Olyan kezdeményezések, mint a Project Treble, kiterjesztett Linux LTS, és Projekt fővonal Segítenek kiküszöbölni a biztonsági javítások összevonásával járó technikai nehézségeket, de ez nem elég ahhoz, hogy az OEM-ek következetesen törekedjenek a frissítések kiadására. A Generic Kernel Image vagy GKI segítségével az SoC-szállítók és az OEM-ek könnyebben egyesíthetik az upstream Linux kernel-javításokat, bár valószínűleg csak jövőre láthatjuk az első GKI-t tartalmazó eszközöket.

De egy érdekes információ, amelyet a legtöbben nem tudnak, az a nagy OEM-ek kell "legalább négy biztonsági frissítést" biztosít az eszköz elindítását követő egy éven belül, és összesen 2 év frissítést. A Google nem erősítette meg ezeket a konkrét feltételeket, de a vállalat megerősítette, hogy "dolgoztak az OEM-szerződéseik biztonsági javításán". Ami az Android Enterprise Recommended (AER) eszközöket illeti, az eszközöknek a megjelenést követő 90 napon belül 3 évig biztonsági frissítéseket kell kapniuk. Robusztus AER eszközök szükségesek a beszerzéshez 5 év biztonsági frissítések közül. Az Android One eszközöknek 3 éven keresztül havonta biztonsági frissítéseket kell kapniuk.

Mi van a biztonsági javításban?

A biztonsági javítás csak egy újabb frissítés, bár általában sokkal kisebb az egyes keretrendszerek és rendszermodulok módosításaival, nem pedig a rendszerszintű fejlesztésekkel vagy változtatásokkal. A Google minden hónapban ellátja az eszközök OEM-jeit egy zip-fájllal, amely tartalmazza a jelenleg még támogatott összes főbb Android-verzió javításait, valamint egy biztonsági tesztcsomagot. Ez a tesztcsomag segít az OEM-eknek megtalálni a biztonsági javítások hiányosságait, hogy ne maradjanak le semmiről és hogy a foltokat megfelelően egyesítették. A hónap előrehaladtával a Google kisebb módosításokat hajthat végre, például úgy dönthet, hogy egy adott javítás nem kötelező, különösen akkor, ha gondok adódnak az implementációval.

Mi a helyzet az egyedi ROM-okkal?

Ha okostelefonja nem kap sok biztonsági frissítést, ez nem feltétlenül jelenti azt, hogy jobb, ha egyéni ROM-ra vált. Bár igaz, hogy olyan biztonsági frissítéseket kap, amelyeket egyébként nem kapott volna, ez csak a történet fele. A rendszerbetöltő feloldásával ki van téve az eszközt érő fizikai támadásoknak, még akkor is, ha a szoftveroldalon a biztonság megkeményedett. Ez nem azt jelenti, hogy ne használj egyedi ROM-okat, csupán más aggályok merülnek fel a használatukkal kapcsolatban, amelyek nem érvényesülnek, ha a rendszerbetöltő zárolva van. Ha jobban aggódik a dolgok szoftveres oldala miatt, akkor még mindig jobban jár egy egyedi ROM, amely gyakran kap biztonsági javításokat.

De emlékszel, hogy beszéltünk az ÉÉÉÉ-HH-01 és az ÉÉÉÉ-HH-05 javítások közötti különbségről? A -05 javítási szint Linux kernel javításokat, valamint gyártói javításokat tartalmaz – zárt forráskódú szoftverekre alkalmazott javításokat. Ez azt jelenti, hogy az egyéni ROM-fejlesztők ki vannak szolgáltatva annak az OEM-nek, amelyre fejlesztenek, és attól, hogy az OEM kiad-e frissített blobokat vagy sem. Ez rendben van azoknál az eszközöknél, amelyeket még frissít a gyártó, de azoknál az eszközöknél, amelyek nem, az alkalmazott javítások csak az Android keretrendszerre és a Linux kernelre alkalmazhatók. Ezért a LineageOS Trust Interface két biztonsági javítási szintet mutat – az egyik a platform, a másik a szállító. Annak ellenére, hogy a nem támogatott eszközök egyedi ROM-jai nem tudják teljesen integrálni a legújabb javításokat, biztonságosabbak lesznek, mint a régebbi, elavult ROM.