A Firefox nemrégiben letiltott kiegészítéseinek műszaki részletei

A fordítási megjegyzés: az olvasók kényelme érdekében a dátumok moszkvai idő szerint szerepelnek

Nemrégiben elmulasztottuk, hogy egy értesítési tanúsítvány határideje lejárt, amelyeket a kiegészítők aláírására használtunk. Ez a kiegészítők kikapcsolásához vezetett a felhasználóknál. Most, hogy a probléma túlnyomó részét már orvosoltuk, szeretném elmondani a történések részleteit és a végzett munkát.

Háttértörténet: kiegészítők és aláírások

Bár sokan "do-it-yourself" böngészőt használnak, a Firefox támogatja a "kiegészítők" néven ismert kiterjesztéseket. Ezek segítségével a felhasználók különféle funkciókat adhatnak a böngészőhöz. Több mint 15 ezer kiegészítő létezik: az hirdetésblokkolásig tól több száz fül kezeléséig.

A telepített kiegészítőknek rendelkezniük kell digitális aláírással, amely megvédi a felhasználókat a káros kiegészítőktől, és minimális ellenőrzést igényel a kiegészítők Mozilla általi jóváhagyásához. Ezt a követelményt 2015-ben vezettük be, mivel komoly problémáink voltak káros kiegészítőkkel.

Hogyan működik: minden Firefox példány tartalmaz egy "gyökér tanúsítványt". Ennek a "gyökérnek" a kulcsa hardveres védelemmel ellátott modulban (HSM), amely nem fér hozzá az internethez. Néhány évente ezzel a kulccsal új "köztes tanúsítványt" írunk alá, amelyet a kiegészítők aláírásához használunk. Amikor egy fejlesztő benyújt egy kiegészítőt, készítünk egy ideiglenes "végső tanúsítványt", és aláírjuk azt a köztes tanúsítvánnyal. Ezt követően a végső tanúsítvány írja alá magát a kiegészítőt. Sémásan így néz ki.

Vegye figyelembe: minden tanúsítványnak van egy "tárgy" (akinek a tanúsítványt kiadták) és egy "kiadó" (aki kiadta a tanúsítványt). A gyökér tanúsítvány esetében a "tárgy" = "kiadó", de más tanúsítványok esetén a tanúsítvány kiadója a felette álló tanúsítványt aláíró tárgy.

Fontos megjegyezni: minden kiegészítő egyedi végső tanúsítvánnyal van aláírva, de szinte mindig ezeket a végső tanúsítványokat ugyanazzal a köztes tanúsítvánnyal írják alá.

A szerző megjegyzése: kivétel a nagyon régi kiegészítők. Akkoriban különböző köztes tanúsítványokat használtak.

Ez az átmeneti tanúsítvány problémákat okozott: minden tanúsítvány meghatározott ideig érvényes. Ezen időszak előtt vagy után a tanúsítvány érvénytelen, és a böngésző nem használja ezt a tanúsítvánnyal aláírt kiegészítőket. Sajnos az átmeneti tanúsítvány érvényességi ideje május 4-én, 4 órakor lejárt.

A következmények nem azonnal jelentkeztek. A Firefox nem folyamatosan ellenőrzi a telepített kiegészítők aláírásait, hanem körülbelül 24 óránként, és a vizsgálati idő felhasználónként eltérő. Ennek eredményeként egyeseknél a problémák azonnal jelentkeztek, másoknál sokkal később. Először akkor értesültünk a problémáról, amikor a tanúsítvány lejárt, és azonnal elkezdtünk megoldást keresni.

Károk csökkentése

Amint megértettük, mi történt, megpróbáltuk elkerülni a helyzet súlyosbodását.

Először is, leállítottuk az új kiegészítők elfogadását és aláírását. Nincs értelme lejárt tanúsítvánnyal ezt tenni. Visszatekintve azt mondanám, hogy talán mindent érintetlenül kellett volna hagyni. Jelenleg a kiegészítők elfogadása újraindult.

Másodszor, azonnal elküldtük a javítást, amely megakadályozta a napi aláírás-ellenőrzéseket. Így megmentettük azokat a felhasználókat, akiknek a böngészője az elmúlt 24 órában még nem ellenőrizte a kiegészítőket. Jelenleg ezt a javítást visszavonták, már nincs rá szükség.

Párhuzamos munkavégzés

Elméletben a probléma megoldása egyszerűen hangzik: létrehozunk egy új érvényes átmeneti tanúsítványt, és újra aláírjuk az összes kiegészítőt. Sajnos ez nem fog működni:

• nem tudjuk gyorsan újra aláírni 15 ezer kiegészítőt egyszerre, a rendszer nem alkalmas ilyen terhelésre.
• az aláírás után az új verziókat el kell juttatni a felhasználókhoz. A legtöbb kiegészítő a Mozilla szervereiről települ, így a következő 24 órában a Firefox frissítéseket talál, de egyes fejlesztők harmadik féltől származó csatornákon terjesztik a aláírt kiegészítőket, ezért a felhasználóknak manuálisan kellett volna frissíteniük ezeket a kiegészítőket.

Ehelyett próbáltunk egy olyan javítást kidolgozni, amely eljut minden felhasználóhoz, anélkül, hogy (vagy szinte anélkül) bárminemű intézkedést igényelne tőlük.

Viszonylag gyorsan eljutottunk két alapvető stratégiához, amelyeket párhuzamosan használtunk:

• Frissítse a Firefoxot a tanúsítvány érvényességi idejének megváltoztatásához. Ez varázslatos módon működővé teszi a meglévő bővítményeket, de új Firefox-verzió kiadását és terjesztését követeli meg.
• Hozzon létre egy érvényes tanúsítványt, és valahogy győzze meg a Firefoxot, hogy azt fogadja el a meglévő, lejárt helyett.

Elsőként az első lehetőséget választottuk, amely teljesen működőképesnek tűnt. A nap végén kiadtuk a második javítást (új tanúsítvány), amelyről később beszélünk.

Tanúsítvány csere

Ahogy már említettem, szükséges volt:

• új, érvényes tanúsítványt létrehozni
• távolról telepíteni azt a Firefoxba

Ahhoz, hogy megértsük, miért működik ez, vizsgáljuk meg alaposabban a bővítmények ellenőrzési folyamatát. Maga a bővítmény egy fájlokból álló készletként kerül forgalomba, beleértve a használt tanúsítványok láncolatát a digitális aláíráshoz. Ennek eredményeként a bővítmény ellenőrizhető, ha a böngésző számára ismert a gyökér tanúsítvány, amelyet a Firefox a build során épít be. Azonban, amint már tudjuk, az közbenső tanúsítvány lejárt, így a bővítmény ellenőrzése lehetetlen.

Amikor a Firefox megpróbálja ellenőrizni a bővítményt, nem csupán a bővítmény belsejében található tanúsítványokat használja. Ehelyett a böngésző megpróbál egy érvényes tanúsítvány-láncot létrehozni, kezdve a végső tanúsítványtól, és folytatva, amíg el nem jut a gyökérhez. Az első szinten a végső tanúsítvánnyal kezdjük, majd megtaláljuk a tanúsítványt, amelynek alany a végső tanúsítvány kiadója (azaz, a közbenső tanúsítvány). Általában ez a közbenső tanúsítvány a bővítménnyel együtt kerül forgalomba, de szerepet játszhat bármely tanúsítvány is a böngésző tárolójából. Ha távolról hozzá tudunk adni egy új, érvényes tanúsítványt a tanúsítványok tárolójához, a Firefox megpróbálja azt használni. A helyzet az új tanúsítvány telepítése előtt és után.

Az új tanúsítvány telepítése után a Firefoxnak két lehetősége van a tanúsítványlánc ellenőrzésére: a régi, érvénytelen tanúsítvány (ami nem fog működni) vagy az új, érvényes (ami működni fog). Fontos, hogy az új tanúsítvány ugyanazt a témanevet és nyilvános kulcsot tartalmazza, mint a régi tanúsítvány, így a végső tanúsítvány aláírása érvényes lesz. A Firefox elég okos ahhoz, hogy mindkét lehetőséget kipróbálja, amíg meg nem találja a működőt, így a kiegészítők ismét ellenőrzöttek lesznek. Ne feledjük, ez ugyanaz a logika, amit a TLS tanúsítványok ellenőrzésére használunk.

Szerzői megjegyzés: azok a olvasók, akik ismerik a WebPKI-t, észre fogják venni, hogy a kereszttanúsítványok pontosan így működnek.

A legcsodálatosabb ebben a javításban, hogy nem szükséges újra aláírni a meglévő kiegészítőket. Amint a böngésző megkapja az új tanúsítványt, minden kiegészítő újra működni fog. A kihívás az új tanúsítvány felhasználókhoz való eljuttatása (automatikusan és távolról), valamint a Firefox újraellenőrzése az inaktív kiegészítők esetében.

Normandy és a kutatási rendszer

Ironikus módon ezt a problémát egy speciális kiegészítő, az 'rendszerszintű' oldja meg. A kutatások lebonyolításához kifejlesztettünk egy Normandy nevű rendszert, amely a kutatásokat a felhasználókhoz juttatja el. Ezek a kutatások automatikusan végrehajtódnak a böngészőben, és kiterjesztett hozzáféréssel rendelkeznek a Firefox belső API felületeihez. A kutatások új tanúsítványokat adhatnak hozzá a tanúsítványtárhoz.

Szerzői megjegyzés: nem adunk hozzá tanúsítványt különleges jogkörökkel; azt egy gyökér tanúsítvány írja alá, így a Firefox bízik benne. Csak hozzáadjuk a tanúsítványok pooljához, amelyeket a böngésző használhat.

Így a megoldás az, hogy létrehozunk egy kutatást:

• amely telepíti a felhasználók számára általunk létrehozott új tanúsítványt
• amely arra készteti a böngészőt, hogy újra ellenőrizze az inaktív kiegészítőket, hogy újra működjenek

"De várj!" – mondod, "a kiegészítők nem működnek, hogyan indítsuk el a rendszerszintű kiegészítőt?" Aláírjuk az új tanúsítvánnyal!

Összehozzuk mindezt... miért tart ez olyan sokáig?

Tehát a terv: új tanúsítvány kiadása a régi helyett, rendszerszintű kiegészítő létrehozása és telepítése a felhasználóknak a Normandy segítségével. A problémák, ahogy említettem, május 4-én 4:00-kor kezdődtek, és már 12:44-kor, kevesebb mint 9 óra elteltével, elküldtük a javítást a Normandynak. További 6-12 órára volt szükség, hogy eljusson minden felhasználóhoz. Ez már nem rossz, de a Twitteren a felhasználók azt kérdezik, miért nem tudtunk gyorsabban cselekedni.

Először is idő szükséges az új közbenső tanúsítvány kiadásához. Ahogy korábban említettem, a gyökér tanúsítvány kulcsa egy dedikált biztonsági modulban tárolódik. Ez biztonsági szempontból jó, mivel a gyökér nagyon ritkán használt és biztonságosan kell védeni, de kissé kényelmetlen, amikor sürgősen kell aláírni egy új tanúsítványt. Az egyik mérnökünknek el kellett utaznia a HSM tárolóhoz. Ezután voltak sikertelen próbálkozások a helyes tanúsítvány kiadására, és mindegyik próbálkozás egy-két órát emésztett fel teszteléssel.

Másodszor, a rendszerszintű kiegészítő fejlesztése is időbe telt. Koncepcionálisan nagyon egyszerű, de még a legegyszerűbb programok is figyelmet igényelnek. Biztosra akartunk menni, hogy ne rontsuk el a helyzetet még jobban. A kutatást tesztelni kell azelőtt, hogy a felhasználóknak küldenénk. Ezen kívül a kiegészítőt alá is kell írni, de az aláírási rendszerünk ki volt kapcsolva, így alternatív megoldásokat kellett keresnünk.

Végül, miután előkészítettük a kutatást a küldésre, a telepítéshez időre volt szükség. A böngésző 6 óránként ellenőrzi a Normandy frissítéseit. Nem minden számítógép van folyamatosan bekapcsolva és internetkapcsolattal, ezért időre van szükség, hogy a javítás eljusson a felhasználókhoz.

Végső lépések

A kutatás a legtöbb felhasználónál javítani fogja a problémát, de nem mindenki számára elérhető. Néhány felhasználónál speciális megközelítésre van szükség:

• a felhasználók, akik letiltották a frissítéseket vagy a telemetriát
• Android verziójú felhasználók (Fennec), ahol a kutatások egyáltalán nem támogatottak
• a vállalati egyedi Firefox ESR verziókat használó felhasználók, ahol a telemetria engedélyezése lehetetlen
• a MitM-proxyn ülő felhasználók, mivel a bővítmények telepítésének rendszere kulcskötést használ, ami nem működik ilyen proxikkal
• elavult Firefox verziót használó felhasználók, amelyek nem támogatják a kutatásokat

Ellenük semmit sem tehetünk – nekik mindenképpen frissíteniük kellene az új Firefox verzióra, mivel az elavultak súlyos nyitott sebezhetőségeket jelentenek. Tisztában vagyunk azzal, hogy néhányan régi Firefox verziókon maradnak, mert régi bővítményeket akarnak futtatni, de sok régi bővítményt már átkonvertáltak az új böngésző verziókhoz. A többi felhasználó számára egy javítást készítettünk, amely új tanúsítványt telepít. Ez a hibajavító kiadás keretében jelent meg (fordítói megjegyzés: Firefox 66.0.5), így a felhasználók valószínűleg már megkapták a szokásos frissítési csatornán keresztül. Ha egy egyedi Firefox ESR kiadást használ, forduljon a karbantartójához.

Megértjük, hogy ez nem tökéletes. Egyes esetekben a felhasználók adatokat veszítettek a bővítményeikből (például a bővítmény adatai) Multi-Account Containers).

Ennek a mellékhatásnak nem lehetett elkerülni, de úgy véljük, hogy rövid távon a többségi felhasználóknak a legjobbat választottuk. Hosszú távon más, kifinomultabb architekturális megoldásokat keresünk.

Tanulságok

Először is, csapatunk fantasztikus munkát végzett, hiszen kevesebb mint 12 órával a probléma felfedezése után létrehozták és elküldték a javítást. Mint aki részt vett a megbeszéléseken, elmondhatom, hogy ebben a bonyolult helyzetben az emberek nagyon keményen dolgoztak, és alig pazaroltak el időt.

Nyilvánvaló, hogy mindezeknek meg sem kellett volna történniük. Határozottan ki kell igazítanunk a folyamataikat, hogy csökkentsük az ilyen incidensek valószínűségét és megkönnyítsük a következmények kijavítását.

Jövő héten közzétesszük a hivatalos post-mortemot és a módosítások listáját, amelyeket végrehajtani kívánunk. Addig is megosztom a gondolataimat. Először is, jobb módszernek kell lennie arra, hogy nyomon kövessük azokat a potenciális időzített bombákat, amelyekkel szemben óvatosak kell legyünk. Biztosnak kell lennünk abban, hogy nem kerülünk olyan helyzetbe, amikor egyikük hirtelen működésbe lép. Még dolgozunk a részleteken, de legalább szükséges nyilvántartást vezetni az ilyen dolgokról.

Másodszor, szükség van egy gyors frissítési mechanizmusra a felhasználók számára, még akkor is, amikor — különösen amikor — minden más nem működik. Nagyszerű volt, hogy tudtuk használni a „kutatási” rendszert, de ez nem tökéletes eszköz, és van néhány nemkívánatos mellékhatása. Különösen tudjuk, hogy sok felhasználónak be van kapcsolva az automatikus frissítés, de inkább nem vennének részt a kutatásokban (bevallom, nekem is le van kapcsolva!). Ugyanakkor szükségünk van egy módra, hogy frissítéseket küldjünk a felhasználóknak, de bármilyen belső technikai megvalósítás mellett a felhasználóknak lehetőséget kell adni arra, hogy feliratkozzanak a frissítésekre (beleértve a sürgős javításokat), de lemondhassanak minden másról. Ezenkívül a frissítési csatornának reagálékonyabbnak kell lennie, mint jelenleg. Május 6-án még voltak felhasználók, akik nem használták sem a javítást, sem az új verziót. Már dolgoztunk ezen a problémán, de az események rávilágítottak, mennyire fontos ez.

Végül megvizsgáljuk a kiegészítők biztonsági architektúráját, hogy megbizonyosodjunk róla, hogy megfelelő biztonsági szintet nyújt minimális kockázat mellett a működés megszakítása érdekében.

Jövő héten megvizsgáljuk a történések alaposabb elemzésének eredményeit, addig is szívesen válaszolok a kérdésekre e-mailben: ekr-blog@mozilla.com

Forrás: linux.org.ru