Az Android Open Source Projectben felfedezett közelmúltbeli kötelezettségvállalásunk szerint a Google készül hogy különbséget tegyen a gyártó biztonsági javítási szintje és az Android Framework biztonsági javítás között szint. Ez lehetővé teszi az OEM-ek számára, hogy frissítsék az Androidot, miközben a hardvergyártókra várnak javításokat.
Korai történetében az Android hosszú ideig kevésbé biztonságos hírében állt, mint az iOS, az Apple „falazott kertje” megközelítése miatt. Nem fogunk belemerülni abba, hogy ez a múltbeli hírnév megérdemelt-e vagy sem, de nyilvánvaló, hogy a Google nagy lépéseket tett az Android biztonsági rések elleni védelmében. A vállalat nemcsak új biztonsági funkciókat kínál az Android legújabb verziójában, Android P, de ők is biztosítanak "vállalati szintű biztonság" legújabb eszközeikben a Google Pixel 2/2 XL hardveres biztonsági moduljának köszönhetően. Az eszközök biztonságának megőrzése folyamatos frissítéseket is igényel a legújabb fenyegetések javítása érdekében, ezért a Google ezt is megtette
havi biztonsági közlemények minden eszközgyártó és -gyártó számára, hogy javítsa az összes ismert aktív és potenciális sebezhetőséget. Most úgy tűnik, hogy a vállalat változtatásokat hajt végre az Android Security Patch rendszeren azáltal, hogy módot ad erre különbséget tenni az Android keretrendszer javítási szintje és a szállítói javítás szintje között a rendszerbetöltővel, kernellel stb. vagy felosztja a biztonsági javítások szintjeit, hogy az OEM-ek tisztán keretrendszer-frissítéseket biztosíthassanak, vagy jobban azonosítsák a felhasználó számára, hogy milyen javítási szintet futtatnak.Havi Android biztonsági javítások – alapozó
Mindannyian tudjuk, hogy a biztonsági javítások fontosak, különösen azután, hogy a tavalyi év második felében egy sor nagy horderejű sebezhetőséget nyilvánosságra hoztak. A BlueBorne sebezhetőség megtámadta a Bluetooth protokollt, és befoltozták a 2017 szeptemberi havi javítások, KRACK a Wi-Fi WPA2 gyengeségét célozza meg, és be lett javítva 2017. december, és a Spectre/Meltdown sebezhetőségét többnyire a 2018. januári javítások. Az ilyen sérülékenységek kijavításához általában együttműködésre van szükség egy hardvergyártóval (például a Broadcommal és Qualcomm), mert a sérülékenység egy hardverkomponensre, például a Wi-Fi- vagy Bluetooth-chipre vagy a CPU. Másrészt az Android operációs rendszerben vannak ilyen problémák pohárköszöntő üzenet overlay támadás amelyek javításához csak az Android Framework frissítésére van szükség.
Amikor a Google kiad egy havi biztonsági javítást, az eszközgyártóknak ki kell javítaniuk az ÖSSZES biztonsági rést. az adott havi biztonsági közleményben, ha azt akarják mondani, hogy eszközük biztonságos a havi javításig szint. Minden hónapban két biztonsági javítási szinttel találkozhat egy eszköz: a hónap 1-jén vagy 5-én érvényes javítási szint. Ha egy eszköz azt mondja, hogy a hónap 1. napjától fut egy javítási szint (pl. április 1. helyett április 5.), akkor ez azt jelenti, hogy a build tartalmazza az összes keretrendszer- ÉS szállítói javítást a múlt havi kiadásból, valamint a legújabb biztonsági közlemény összes keretrendszer-javítását. Másrészt, ha egy eszköz azt mondja, hogy a hónap 5. napjától (április 5. példa), akkor ez azt jelenti, hogy tartalmazza az összes keret- és szállítói javítást a múlt hónapból és az e haviból közlöny. Íme egy táblázat, amely szemlélteti a havi javítási szintek közötti alapvető különbségeket:
Havi biztonsági javítási szint |
április 1 |
április 5 |
---|---|---|
April Framework javításokat tartalmaz |
Igen |
Igen |
Április szállítói javításokat tartalmaz |
Nem |
Igen |
March Framework javításokat tartalmaz |
Igen |
Igen |
márciusi szállítói javításokat tartalmaz |
Igen |
Igen |
Valószínűleg Ön is tisztában van azzal, milyen szomorú a biztonsági javítások helyzete az Android ökoszisztémájában. Az alábbi táblázat azt mutatja, hogy a Google és az Essential biztosítja a leggyorsabb havi biztonsági javítási frissítéseket, míg más cégek elmaradnak. Hónapokba telhet, amíg az OEM-nek eljuttatja a legújabb javításokat az eszközhöz, például hogyan a OnePlus 5 és OnePlus 5T nemrég kapta meg a Április biztonsági javítás amikor korábban a decemberi folton voltak.
Az Android biztonsági javítás állapota 2018 februárjában. Forrás: @SecX13
Az Android Security Patch frissítéseinek biztosításával kapcsolatos probléma nem feltétlenül az, hogy az OEM-ek lusták, mivel ez néha kikerülhet az irányításuk alól. Ahogy korábban említettük, a havi biztonsági javítások frissítése gyakran hardver együttműködését igényli szállító, ami késéseket okozhat, ha a szállító nem tud lépést tartani a havi biztonsági javítással közlemények. Ennek leküzdésére úgy tűnik, hogy a Google elkezdheti elválasztani az Android Framework biztonsági javítás szintjét a gyártói javítás szintjétől (és esetleg a rendszerbetöltő és a kernel szintje), hogy a jövőben az OEM-ek tisztán Android keretrendszerű biztonságot nyújthassanak frissítéseket.
Gyorsabb Android Security Patch frissítések a keretrendszer sebezhetőségeihez?
Egy új elkövetni megjelent az Android Open Source Project (AOSP) gerritben, amely a "szállító biztonsági javítására" utal prop", amely az Android.mk fájlokban kerül meghatározásra, amikor egy eszköz új buildje készül létre. Ennek az ingatlannak a neve "ro.vendor.build.security_patch
"és analóg lesz"ro.build.version.security_patch
", amely jelenleg minden Android-eszközön létezik, és meghatározza a havi Android biztonsági javítás szintjét.
Ez az új ingatlan ehelyett a "VENDOR_SECURITY_PATCH
" szintű eszközön, amely megegyezik az Android Framework biztonsági javítás szintjével, de lehet, hogy nem. Például előfordulhat, hogy egy eszköz a legújabb, 2018. áprilisi keretrendszer-javításokon fut, valamint a 2018. februári gyártói javításokon. A két biztonsági javítási szint megkülönböztetésével lehetséges, hogy a Google engedélyezni kívánja az OEM-ek számára a az Android operációs rendszer legújabb biztonsági javításait, bár a gyártók nem biztosítottak frissített javításokat az adott havi javításhoz szint.
Alternatív megoldásként, Google csak a minimumot jelenítheti meg a két javítási szint közül (esetleg a rendszerbetöltő és a kernel javítási szintjei mellett), hogy pontosabban megmutassa a felhasználónak, hogy milyen biztonsági javításon van az eszköze. Még nincs megerősítésünk a javítás mögötti szándékról, de reméljük, hogy hamarosan többet megtudunk.
Ez legalábbis hasznos lesz azoknak, akik most vagyunk Projekt TrebleÁltalános rendszerképek (GSI) és más AOSP-alapú egyéni ROM-ok, mivel az egyéni ROM-ok gyakran csak keretfrissítéseket biztosítanak az összes gyártó javítása nélkül, rendszerbetöltőt és a havi biztonsági közleményben megadott kernelfoltokat, így az eltérés zavart okoz a felhasználók között, úgy gondolja, hogy a legújabb javításokat futtatják, miközben a valóságban az eszközük csak részben van javítva a legújabb havi biztonság ellen közlöny.