A firmware határozza meg, hogy egy eszköz miben bízik meg, mit futtat, és mely biztonsági javítások vannak ténylegesen aktívak. Amikor egy gyártó frissítést küld ki, a nyilvánvaló cél a sebezhetőségek javítása, az ellenőrzések szigorítása, és a tegnap még működő trükkök letiltása. A kellemetlen igazság az, hogy a tegnapi firmware nem feltétlenül tűnik el. Még egy frissítés után is, az előző firmware továbbra is elérhető lehet hivatalos gyári képként vagy teljes OTA csomagként.
Szóval mi akadályozza meg, hogy valaki egyszerűen telepítse azt a régebbi buildet és újra megnyisson egy már javított sebezhetőséget? Ebben a cikkben lebontjuk az Anti-Rollback Protection-t (ARB) és azt, hogyan érvényesít egy csak előre mutató biztonsági alapszintet valós eszközökön.
Mi az Anti-Rollback Protection (ARB)?
Általában csak akkor veszi észre az ARB-t, amikor valami ésszerű dolgot próbál csinálni, és az eszköz megtagadja. Talán egy frissítés hibát okozott, és vissza szeretne térni az utolsó stabil buildhez. Talán egy szerviznek régebbi képre van szüksége egy kézi telefon helyreállításához. Az ARB ezeket a visszafelé lépéseket kemény megállássá változtatja.
Ez nem egy vadonatúj találmány, de mostanában sokkal agresszívebben vezetik be. A downgrade támadások gyakorlati forgatókönyvvé váltak, és a megfelelőségi nyomás növekszik, az EU Cyber Resilience Act-től az autóipar világában az UNECE R155/R156-ig és az újabb IoT biztonsági alapszintekig. Az ipar nem hirtelen fedezte fel a rollback védelmet. Inkább elérte azt a pontot, ahol a downgrade ajtó nyitva hagyása vakmerőség lett volna.
A terminológiai különbség
Az Anti-Rollback Protection-t különböző terminológiával írják le, ami miatt könnyen azt lehet gondolni, hogy több különböző „zár” van, amikor egy ötlet rejlik alatta.
Androidon a Google hivatalos kifejezése a rollback protection a Verified Boot-on belül, rollback indexekkel implementálva, amelyeket az eszköz ellenőriz bootolás során. Felhasználói és technikus körökben ugyanezt a viselkedést általában ARB-nek nevezik, az Anti-Rollback rövidítéseként.
A gyártók aztán saját címkéiket adják hozzá. A Fuse vagy eFuse is használatos, mivel a minimum elfogadott verzió egyszer programozható bitekben van tárolva a chipen belül. Az OTP kifejezést is használják ugyanezért az okért, ami egyszer programozható memóriát jelent. A mobilpiacon gyakran látni, hogy a Samsung rollback szintjét „binary” revíziónak nevezik, vagy szerviz nyelvben „BIT”-nek, mert így jelenik meg ugyanez az csak előre mutató határ az ő flash és javítási munkafolyamataikban.
Függetlenül a szóhasználattól, az eredmény ugyanaz. Amint az eszköz rögzít egy minimum elfogadott biztonsági verziót, megtagadja bármi régebbi bootolását, mint az az alapszint. A legegyszerűbb módja ennek elképzelésére egy racsni: a frissítések előre mozdíthatják a minimumot, de normál szoftver nem tudja visszafelé mozgatni.
Gyakran úgy magyarázzák, mint amit a Google az Android 8-cal (Oreo) vezetett be. Ez a keretezés közel van, de nem egészen precíz. Az Android 8 az a pont, ahol a rollback védelem standardizálttá vált és rendszer-integrálttá olyan módon, ami lehetővé tette az Android ökoszisztéma számára, hogy köré rendeződjön.
A közelmúltbeli OnePlus körüli jelentések újra fókuszba hozták az ARB-t, de a hardver által kényszerített rollback megelőzés alapötlete sokkal régebbi. A jelenlegi diskurzust jobban úgy lehet megérteni, mint a kényszerítés friss hullámát újabb firmware buildeken, nem pedig egy teljesen új biztonsági koncepció bevezetéseként.
A biztonsági probléma, amit az ARB kezel
Egy downgrade támadás során a támadónak nem kell aláírásokat hamisítania vagy egyedi firmware-t kitalálnia. Egyszerűen visszatolja az eszközt egy régebbi buildhez, ami még mindig aláírt, még mindig hivatalosnak néz ki, és még mindig tartalmaz gyengeségeket, amiket már feltérképeztek.
Ez az a rés, amit az ARB bezár. A Secure Boot meg tudja mondani, hogy a firmware eredeti, de önmagában nem garantálja, hogy a firmware elég friss ahhoz, hogy biztonságos legyen. Ha régebbi aláírt képek továbbra is elfogadhatók, akkor az újabb kiadásokban szállított javítások a gyakorlatban opcionálissá válnak. A támadók a legkönnyebb utat választják, és visszafelé menni könnyebb lehet, mint az előrefelé védelmek megtörése.
Az ARB blokkolja ezt a lépést. Amint az eszköz átlépett egy bizonyos küszöböt, a vissza-az-időben trükk már nem működik. A támadó elveszíti a könnyű győzelmek egy egész kategóriáját, mert az eszköz nem hajlandó szántszándékkal belépni egy régebbi, gyengébb állapotba.
Hardver által kényszerített verzió határok
A tárhely újra flash-elése, képek újratelepítése, vagy partíciók cseréje nem változtatja meg azt, amit az eszköz már rögzített elfogadhatóként. Amint egy újabb alapszint tárolásra kerül, a régebbi verziók elfogadhatatlannak minősülnek, még akkor is, ha helyesen aláírottak és csomagoltak.
Ez az oka annak, hogy a „hivatalos firmware” nem mindig jelent „flash-elhető firmware-t” többé, miután egy eszköz előrelépett, különösen valódi szerviz forgatókönyvekben, ahol a technikusok egy régebbi buildet próbálnak és kemény elutasításba ütköznek figyelmeztetés helyett.
Miért nem szoftver házirend az ARB
Az anti-rollback védelem nem gyártói preferencia a frissítőben. A küszöb nem csökkenthető vagy állítható vissza, mert a tárolt érték visszafordíthatatlanra van tervezve.
Ha a minimum verzió szerkeszthető lenne, a támadók először azt a mechanizmust vennék célba. Az ARB elkerüli ezt a csapdát azzal, hogy az eszköz frissítési előzményeit olyanná teszi, amit a szoftver nem tud újraírni. Amint a minimum verzió előrelép, a platform azt kényszerített alapszintként kezeli attól a ponttól kezdve.
Hogyan működik az ARB boot időben
A boot folyamat ellenőrzött átadások sorozata. Minden szakasznak meghatározott feladata van, és minden szakasz ellenőrzi a következőt, mielőtt a kontroll előremozogna. Az ARB egy egyszerű kérdést fűz ebbe a folyamatba: Az, amit futtatni készülsz, legalább olyan új, mint amit az eszköz megkövetel?
Firmware verzió indexek
Minden firmware kép, ami részt vesz a verified boot-ban, verzió információt hordoz. Ez az érték biztonsági verzió indexként van leírva. A magasabb számok a gyártó frissítési idővonalának későbbi pontjait jelentik, ahol több problémát javítottak, és több védelmet vezettek be.
Az ARB-vel az eszköz rögzít egy minimum elfogadható verziót hardver-támogatott tárolóban, és minden jelölt képet ehhez a tárolt referencához hasonlít. Az eszköz hatékonyan emlékszik arra, mennyire lépett előre, és a jövőbeli boot kísérleteknek tiszteletben kell tartaniuk ezt a progressziót.
Gyakorlati értelemben az ARB néhány visszafelé lépést állandó nem-opciókká tesz. Egy build, ami régen bootolt, örökre elfogadhatatlanná válhat, miután az eszköz rögzített egy magasabb minimumot.
A Boot lánc ellenőrzési modell
Maga a boot folyamat láncként van strukturálva. Minden szakasz ellenőrzi a következő szakasz integritását és eredetét, mielőtt átadná a kontrollt. Aláírások ellenőrzésre kerülnek minden lépésben, és a verzió adatok kiértékelésre kerülnek ezen aláírások mellett.
Fontos megjegyezni azt is, hogy nem minden komponensnek kell ütemben előre lépnie. A gyártók gyakran függetlenül frissítik a lánc részeit. Minden elem kontextusban van validálva, és a tárolt minimummal való összehasonlítás ott történik, ahol számít.
Ez az egyik oka annak, hogy az emberek összezavarodik, amikor ARB falba ütköznek. Egy egyszerű firmware verziót várnak, de a boot-kritikus komponensek külön verzió határokkal rendelkezhetnek, amik különböző módon számítanak.
BootROM
A boot lánc elején a BootROM van, egy megváltoztathatatlan kód, ami a chipbe van égetve és a bizalom gyökereként működik. A gyártók másként címkézhetik az első szakaszt (például a Qualcomm Primary Boot Loader-nek vagy PBL-nek hívja), de a szerep ugyanaz. A boot egy rögzített, megbízható alapból indul.
Attól a ponttól kezdve rollback ellenőrzések már alkalmazhatók, mert a korai boot kód olvassa a tárolt minimum verziót és blokkolja az alá eső szakaszokat, és a támadók nem tudják újraírni azt az első réteget a szabály megkerüléséhez.
Samsungnál ez általában az a pillanat, amikor az emberek felfedezik az anti-rollback gyakorlati jelentését, ahol downgrade-et kísérelnek meg és egyenesen beleütköznek egy SW REV / binary falba.
Miért nem elég csak a Secure Boot
A Secure Boot helyesen van leírva mint a modern eszköz bizalom alapja. Biztosítja, hogy minden szakasz a boot szekvenciában jóváhagyott forrásból származik és nem lett megváltoztatva. Amit nem garantál, az hogy a jóváhagyott kód elég friss ahhoz, hogy biztonságos legyen. A Secure Boot kiváló abban, hogy megválaszolja, a firmware hiteles-e. Nem válaszolja meg, hogy a firmware elavult-e.
Mit ellenőriz ténylegesen a Secure Boot
A Secure Boot biztosítja, hogy az eszköz boot során használt szoftvert az OEM megbízhatónak tartja. Egy firmware képnek digitálisan aláírtnak kell lennie, és az aláírásnak egyeznie kell a végrehajtásra kerülő tartalommal. Ha ezek a feltételek teljesülnek, a kép hitelesség szempontjából érvényes.
Életciklus perspektívából ez csak a történet egy része. A régi verziók hosszú ideig maradhatnak érvényesen aláírva, és ez pontosan a downgrade támadások lehetősége.
Az aláírt de sebezhetó probléma
Egy régebbi firmware verzió átmehet minden hitelesség ellenőrzésen és mégis kitehető támadási útvonalaknak, amiket már tanulmányoztak. A biztonsági tanácsadások gyakran leírnak problémákat, amik korábbi buildekben léteznek, de később megszüntetésre kerülnek. Ha egy eszköz folyamatosan elfogadja a korábbi buildeket, akkor azok a későbbi javítások csak addig hasznosak, amíg senki sem tud visszacsévélni.
Egy minimum verzió kényszerítésével az ARB blokkolja a visszatérést olyan állapotokhoz, ahol ismert gyengeségek még léteznek.
Hogyan működnek a downgrade támadások a gyakorlatban
Egy downgrade támadás ismerős mintát követ. Az eszköz arra kényszerül vagy rávétetik, hogy egy régebbi buildet telepítsen. A támadó aztán egy exploitot használ, ami csak azon a régebbi builden működik. Amint van támasztékuk, megkísérelhetnek megmaradást, adat hozzáférést, vagy mélyebb módosításokat.
A Secure Boot önmagában nem állítja meg ezt, ha a régebbi firmware még helyesen aláírt. Az ARB megszakítja a láncot az első lépésben azzal, hogy elsősorban megtagadja a downgrade-et.
ARB mint firmware frissesség kényszerítés
A Secure Boot-tal kombinálva az ARB második dimenziót ad a bizalomhoz. Együtt bezárják a rést, amire a downgrade támadások támaszkodnak. Hitelesség verzió kontrol nélkül teret hagy a regressziónak. Verzió kontrol hitelesség nélkül lehetővé tenné nem megbízható kód futtatását. Amikor mindkettő jelen van, a platform eredetet és frissességet kényszerít.
Tipikus használati esetek és telepítési területek
Bármely platform, ami firmware frissítéseken keresztül fejlődik és idővel meg kell őriznie biztonsági állását, profitál az ARB-ből.
Android mobil eszközök
Sok modern Android telefon implementálja az ARB-t a boot és frissítés tervezésének részeként. Minden biztonsági patch szint előre mozgatja a platformot gyengeségek bezárásával. A korábbi patch szintekhez való visszatérés engedélyezése újra bevezetné a már kezelt problémákat.
Egy minimum elfogadott verzió kényszerítésével az ARB az eszközt a legfrissebb biztonsági állapotához igazítva tartja. Amint a platform előrelép, az a szint lesz a jövőbeli bootok és flash-ek alapszintje.
Játékkonzolok
A rollback védelem szintén ismerős a játékkonzolokon keresztül. Ezek a rendszerek firmware frissítéseket kapnak, amik bezárják az exploit útvonalakat és módosítják a biztonsági kontrolokat. Ha régebbi firmware szabadon visszaállítható lenne, az ismert gyengeségek állandó belépési pont maradnának.
A konzol platformok ezért csak előre mutató küszöböket használnak, amik megakadályozzák a regressziót bizonyos pontokon túl. Amint a rendszer előrelép, a korábbi generációkhoz való visszatérés blokkolva van, ami helyben tartja a későbbi biztonsági fejlesztéseket.
Beágyazott és ipari rendszerek
A hosszú élettartamú beágyazott eszközök és ipari berendezések gyakran olyan környezetekben működnek, ahol a fizikai hozzáférés reális, és a frissítési ciklusok lassúak lehetnek. Idővel a firmware revíziók kezelik a felfedezett gyengeségeket. Egy régebbi buildhez való visszagurulás kitehetné a rendszert már ismert fenyegetéseknek.
Az ARB segít megakadályozni ezt a visszafelé sodródást. Amint egy új minimum verzió rögzítésre kerül, a korábbi állapotok már nem elfogadottak. Ez támogatja a konzisztens biztonsági alapszintet az eszköz működési élete során.
Autóipari ECU-k
Az autóipari elektronikus kontrollegységek olyan funkciókat kezelnek, amik befolyásolják a biztonságot és rendszer viselkedést. A firmware frissítések válaszolnak biztonsági megállapításokra és kiberbiztonsági értékelésekre. A regresszió engedélyezése aláásná ezeket a fejlesztéseket.
Az ARB-stílusú kényszerítés biztosítja, hogy amint egy kontrol egység újabb firmware szintre lép, nem tér vissza egy régebbi, kevésbé védett állapotba. Ez támogatja a biztonsági elvárásokat és a modern over-the-air frissítési stratégiák integritását.
Mi a hátrány?
Ugyanazok a tulajdonságok, amik értékessé teszik az anti-rollback-ot telepített rendszerekben, súrlódást okoznak fejlesztés során. Amint verzió küszöbök visszafordíthatatlan mechanizmusokhoz kötődnek, a rugalmasság csökken, és a hibák állandóvá válhatnak.
Visszafordíthatatlan Fuse és OTP kockázatok
A minimum megengedett firmware verzió hardver-támogatott helyeken van tárolva, amik hamisítás-ellenállóak kívánnak lenni, szóval egy fejlesztői vagy teszt eszköz végezhet azzal, hogy megtagadja a buildeket, amikre a mérnököknek még szüksége van, ha rossz küszöb került rögzítésre.
A szokásos konfigurációs hibákkal ellentétben ezt nem feltétlenül tudja megjavítani szoftver újratelepítéssel, mert a rollback védelem a verified boot alatt van kényszerítve és kifejezetten arra van tervezve, hogy megtagadja régebbi verziók bootolását, amint magasabb alapszint rögzítésre került.
Ezért korlátozott lehet a helyreállítás. Amint átlép egy rollback határt, a szokásos „csak flash-elj egy régebbi buildet” tartalék blokkolható, és néhány platformon a rossz vonalon keresztüli downgrade széles körben brick kockázatként van jelentve, visszafordítható hiba helyett.
Hibakeresési korlátok
A hibaelhárítás gyakran magában foglalja a viselkedés összehasonlítását revíziók között. A mérnököknek szükségük lehet egy korábbi buildhez való visszatérésre egy probléma reprodukálásához vagy annak megerősítéséhez, mikor jelent meg először egy probléma. Az ARB helyén lévővel ezek a visszafelé lépések többé nem lehetségesek olyan eszközökön, amik már átléptek egy küszöböt.
Ez megváltoztatja, hogyan tervezik a vizsgálatokat. A csapatok külön hardvert tartanak fenn régebbi buildekhez, jobban támaszkodnak szimulációra, vagy jobban befektetnek naplózásba. Az ARB csak előre mutató munkafolyamatokat bátorít, ami frusztráló lehet, amikor egy nehéz hiba hajsza közepén van.
Pipeline koordináció kihívások
A verzió számokat és kiadási sorrendeket gondosan kell kezelni fejlesztés, tesztelés és gyártás között. Ha egy szakasz előbb lépteti előre a minimum verziót, mielőtt mások készek lennének, a csapatok hirtelen képtelenek lehetnek várt firmware kombinációk futtatására megosztott eszközökön.
Az ARB ezért koordinációt követel. A kiadás tervezését, verzió hozzárendelést és frissítés sorrendezést összhangba kell hozni. A biztonsági előnyök egyértelműek, de a működési fegyelem a költség részévé válik.
Összefoglalás
Az ARB nem új ötlet, de most széles körben telepítik, mert a downgrade támadások valós fenyegetési mintává váltak, a megfelelőségi elvárások növekednek, és a fuse/eFuse/OTP-alapú tárolás gyakorlativá és tartóssá teszi a csak előre mutató alapszinteket.
A Chimera Tool egy mindent egyben szoftver megoldást nyújt, ami támogatja a mobil modellek ezreit és komplex szerviz funkciókat. A mobil biztonsági kutatás élvonalában maradva lehetővé teszi a felhasználók számára a firmware kezelését, biztonsági verzi
