Tekniska detaljer om den senaste inaktiveringen av tillägg i Firefox

Notera översättare: för läsarnas bekvämlighet ges datum i Moskva-tid

Vi missade nyligen utgången av ett av certifikaten som används för att signera tillägg. Detta resulterade i att tillägg inaktiverades för användare. Nu när problemet till största delen är åtgärdat vill jag dela med mig av detaljerna om vad som hände och det arbete som gjordes.

Bakgrund: tillägg och signaturer

Även om många använder webbläsaren direkt, stöder Firefox tillägg som kallas "tillägg". Med deras hjälp lägger användarna till olika funktioner i webbläsaren. Det finns över 15 tusen tillägg: från annonsblockering до hantera hundratals flikar.

Installerade tillägg måste ha digital signatur, som skyddar användare från skadliga tillägg och kräver minimal granskning av tillägg av Mozilla-personal. Vi införde detta krav 2015 eftersom vi upplevde allvarliga problem med skadliga tillägg.

Hur det fungerar: Varje kopia av Firefox innehåller ett "rotcertifikat". Nyckeln till denna "rot" lagras i Hårdvarusäkerhetsmodul (HSM)utan nätverksåtkomst. Med några års mellanrum signeras ett nytt "mellancertifikat" med denna nyckel, som används vid signering av tillägg. När en utvecklare skickar in ett tillägg skapar vi ett tillfälligt "slutcertifikat" och signerar det med ett mellancertifikat. Själva tillägget signeras sedan med slutcertifikatet. Schematiskt det ser ut så här.

Observera att varje certifikat har ett "subjekt" (till vilken certifikatet utfärdades) och en "utfärdare" (som utfärdade certifikatet). I fallet med ett rotcertifikat, "ämne" = "utfärdare", men för andra certifikat är utfärdaren av certifikatet föremålet för det överordnade certifikatet som det signeras av.

En viktig punkt: varje tillägg signeras av ett unikt slutcertifikat, men nästan alltid är dessa slutcertifikat signerade av samma mellancertifikat.

Författarens anmärkning: Undantaget är mycket gamla tillägg. Då användes olika mellancertifikat.

Detta mellancertifikat orsakade problem: varje certifikat är giltigt under en viss period. Före eller efter denna period är certifikatet ogiltigt och webbläsaren kommer inte att använda tillägg som signerats av detta certifikat. Tyvärr gick mellancertifikatet ut den 4 maj klockan 4.

Konsekvenserna visade sig inte omedelbart. Firefox kontrollerar inte signaturerna för installerade tillägg konstant, utan ungefär en gång var 24:e timme, och verifieringstiden är individuell för varje användare. Som ett resultat upplevde vissa människor problem direkt, andra mycket senare. Vi blev först medvetna om problemet när certifikatet gick ut och började genast leta efter en lösning.

Minska skador

När vi väl insåg vad som hade hänt försökte vi förhindra att situationen blev värre.

För det första slutade de acceptera och signera nya tillägg. Det är ingen idé att använda ett utgånget certifikat för detta. När jag ser tillbaka skulle jag säga att vi kunde ha lämnat allt som det var. Vi har nu återupptagit att ta emot tillägg.

För det andra skickade de omedelbart ut en fix som förhindrade att signaturer kontrollerades dagligen. Därmed räddade vi de användare vars webbläsare ännu inte hunnit kontrollera tilläggen under de senaste XNUMX timmarna. Denna korrigering har nu dragits tillbaka och behövs inte längre.

Parallell drift

I teorin ser lösningen på problemet enkel ut: skapa ett nytt giltigt mellancertifikat och signera om varje tillägg. Tyvärr kommer detta inte att fungera:

• vi kan inte snabbt signera om 15 tusen tillägg på en gång, systemet är inte designat för en sådan belastning
• Efter att vi har signerat tilläggen måste de uppdaterade versionerna levereras till användarna. De flesta tillägg installeras från Mozilla-servrar, så Firefox kommer att hitta uppdateringar inom de närmaste XNUMX timmarna, men vissa utvecklare distribuerar signerade tillägg via tredjepartskanaler, så användare måste uppdatera sådana tillägg manuellt

Istället försökte vi utveckla en fix som skulle nå alla användare utan att kräva mycket eller ingen åtgärd från deras sida.

Ganska snabbt kom vi fram till två huvudstrategier, som vi använde parallellt:

• Uppdatera Firefox för att ändra certifikatets giltighetstid. Detta kommer att få befintliga tillägg att fungera magiskt igen, men kommer att kräva att en ny version av Firefox släpps och skickas
• Skapa ett giltigt certifikat och på något sätt övertyga Firefox att acceptera det istället för det befintliga som har gått ut

Vi bestämde oss för att använda det första alternativet först, vilket såg ganska fungerande ut. I slutet av dagen släppte de en andra fix (ett nytt certifikat), som vi kommer att prata om senare.

Ersätter ett certifikat

Som jag nämnde ovan krävdes det:

• skapa ett nytt giltigt certifikat
• installera det på distans i Firefox

För att förstå varför detta fungerar, låt oss ta en närmare titt på tilläggsverifieringsprocessen. Själva tillägget kommer som en uppsättning filer, inklusive en kedja av certifikat som används för signering. Som ett resultat kan tillägget verifieras om webbläsaren känner till rotcertifikatet, som är inbyggt i Firefox vid byggtiden. Men som vi redan vet har det mellanliggande certifikatet gått ut, så det är omöjligt att verifiera tillägget.

När Firefox försöker verifiera ett tillägg är det inte begränsat till att använda certifikaten som finns i själva tillägget. Istället försöker webbläsaren skapa en giltig certifikatkedja, som börjar med slutcertifikatet och fortsätter tills det kommer till roten. På första nivån börjar vi med slutbeviset och hittar sedan certifikatet vars ämne är utfärdaren av slutcertifikatet (det vill säga mellancertifikatet). Vanligtvis levereras detta mellancertifikat med tillägget, men vilket certifikat som helst från webbläsarens lagring kan också fungera som detta mellancertifikat. Om vi ​​på distans kan lägga till ett nytt giltigt certifikat till certifikatarkivet kommer Firefox att försöka använda det. Situationen före och efter installation av ett nytt certifikat.

Efter installation av det nya certifikatet kommer Firefox att ha två alternativ när certifikatkedjan valideras: använd det gamla ogiltiga certifikatet (som inte fungerar) eller det nya giltiga certifikatet (som kommer att fungera). Det är viktigt att det nya certifikatet innehåller samma ämnesnamn och publika nyckel som det gamla certifikatet, så dess signatur på det slutliga certifikatet kommer att vara giltig. Firefox är smart nog att prova båda alternativen tills den hittar en som fungerar, så tilläggen testas igen. Observera att detta är samma logik som vi använder för att validera TLS-certifikat.

Författarens anmärkning: Läsare som är bekanta med WebPKI kommer att notera att korscertifikat fungerar på exakt samma sätt.

Det fantastiska med den här korrigeringen är att den inte kräver att du signerar om befintliga tillägg. Så snart webbläsaren får det nya certifikatet kommer alla tillägg att fungera igen. Den återstående utmaningen är att leverera det nya certifikatet till användarna (automatiskt och på distans), samt att få Firefox att omkontrollera inaktiverade tillägg.

Normandie och forskningssystemet

Ironiskt nog löses detta problem med ett speciellt tillägg som kallas "system". För att bedriva forskning utvecklade vi ett system som heter Normandie som levererar forskning till användarna. Dessa studier utförs automatiskt i webbläsaren och har förbättrad tillgång till Firefoxs interna API:er. Forskning kan lägga till nya certifikat till certifikatarkivet.

Författarens anmärkning: Vi lägger inte till ett certifikat med några speciella privilegier; det är signerat av rotcertifikatet, så Firefox litar på det. Vi lägger helt enkelt till den i poolen av certifikat som kan användas av webbläsaren.

Så lösningen är att skapa en studie:

• installera det nya certifikatet vi skapade för användare
• tvingar webbläsaren att kontrollera inaktiverade tillägg igen så att de fungerar igen

"Men vänta", säger du, "tillägg fungerar inte, hur kan jag starta ett systemtillägg?" Låt oss signera det med ett nytt certifikat!

Att lägga ihop allt... varför tar det så lång tid?

Så, planen: utfärda ett nytt certifikat för att ersätta det gamla, skapa ett systemtillägg och installera det för användare via Normandie. Problemen började som sagt den 4 maj klockan 4:00 och redan klockan 12:44 samma dag, mindre än 9 timmar senare, skickade vi en fix till Normandie. Det tog ytterligare 6-12 timmar för den att nå alla användare. Inte illa alls, men folk på Twitter frågar varför vi inte kunde ha agerat snabbare.

För det första tog det tid att utfärda ett nytt mellancertifikat. Som jag nämnde ovan lagras nyckeln till rotcertifikatet offline i hårdvarusäkerhetsmodulen. Detta är bra ur säkerhetssynpunkt, eftersom roten används mycket sällan och bör skyddas på ett tillförlitligt sätt, men det är lite obekvämt när du snabbt behöver signera ett nytt certifikat. En av våra ingenjörer fick åka till HSM:s lager. Sedan gjordes det misslyckade försök att utfärda rätt certifikat, och varje försök kostade en eller två timmars testning.

För det andra tog utvecklingen av systemtillägget lite tid. Konceptuellt är det väldigt enkelt, men även enkla program kräver omsorg. Vi ville se till att vi inte gjorde situationen värre. Forskning måste testas innan den skickas till användare. Dessutom måste tillägget vara signerat, men vårt signeringssystem för tillägg var inaktiverat, så vi var tvungna att hitta en lösning.

Slutligen, när vi hade forskningen klar för inlämning tog implementeringen tid. Webbläsaren söker efter Normandie-uppdateringar var 6:e ​​timme. Alla datorer är inte alltid på och anslutna till Internet, så det kommer att ta tid för korrigeringen att spridas till användarna.

Sista stegen

Forskningen borde lösa problemet för de flesta användare, men är inte tillgänglig för alla. Vissa användare kräver ett speciellt tillvägagångssätt:

• användare som har inaktiverat forskning eller telemetri
• användare av Android-versionen (Fennec), där forskning inte alls stöds
• användare av anpassade versioner av Firefox ESR i företag där telemetri inte kan aktiveras
• användare som sitter bakom MitM-proxyer, eftersom vårt tilläggsinstallationssystem använder nyckelstiftning, vilket inte fungerar med sådana proxyservrar
• användare av äldre versioner av Firefox som inte stöder forskning

Vi kan inte göra något åt ​​den senare kategorin användare – de bör fortfarande uppdatera till den nya versionen av Firefox, eftersom föråldrade sådana har allvarliga opatchade sårbarheter. Vi vet att vissa människor stannar på äldre versioner av Firefox eftersom de vill köra gamla tillägg, men många av de gamla tilläggen har redan porterats till nyare versioner av webbläsaren. För andra användare har vi utvecklat en patch som kommer att installera ett nytt certifikat. Det släpptes som en bugfix-utgåva (översättarens anmärkning: Firefox 66.0.5), så att folk kommer att få det - troligen redan fått det - via den vanliga uppdateringskanalen. Om du använder en anpassad version av Firefox ESR, kontakta din underhållare.

Vi förstår att detta inte är idealiskt. I vissa fall förlorade användare tilläggsdata (till exempel tilläggsdata Behållare med flera konton).

Denna bieffekt gick inte att undvika, men vi tror att vi på kort sikt har valt den bästa lösningen för de flesta användare. På lång sikt kommer vi att leta efter andra, mer avancerade arkitektoniska angreppssätt.

Lektionerna

Först gjorde vårt team ett fantastiskt jobb med att skapa och skicka en fix på mindre än 12 timmar efter att problemet upptäcktes. Som en som deltog i mötena kan jag säga att i den här svåra situationen arbetade människor väldigt hårt och väldigt lite tid gick till spillo.

Uppenbarligen borde inget av detta ha hänt alls. Det är helt klart värt besväret att anpassa våra processer för att minska sannolikheten för sådana incidenter och underlätta saneringen.

Nästa vecka kommer vi att publicera en officiell obduktion och en lista över förändringar vi tänker göra. För nu delar jag med mig av mina tankar. För det första måste det finnas ett bättre sätt att övervaka statusen för vad som är en potentiell tidsinställd bomb. Vi måste vara säkra på att vi inte hamnar i en situation där en av dem plötsligt fungerar. Vi håller fortfarande på att utarbeta detaljerna, men som ett minimum är det nödvändigt att ta hänsyn till alla sådana saker.

För det andra behöver vi en mekanism för att snabbt leverera uppdateringar till användare, även när – särskilt när – allt annat misslyckas. Det var bra att vi kunde använda "forsknings"-systemet, men det är ett imperfekt verktyg och har några oönskade biverkningar. I synnerhet vet vi att många användare har automatiska uppdateringar aktiverade, men föredrar att inte delta i forskning (jag erkänner, jag har dem avstängda också!). Samtidigt behöver vi ett sätt att skicka uppdateringar till användarna, men oavsett den interna tekniska implementeringen ska användare kunna prenumerera på uppdateringar (inklusive snabbkorrigeringar) men välja bort allt annat. Dessutom bör uppdateringskanalen vara mer lyhörd än den är nu. Även den 6 maj fanns det fortfarande användare som inte utnyttjade vare sig fixen eller den nya versionen. Det här problemet har redan arbetats med, men det som hände visade hur viktigt det är.

Slutligen ska vi titta närmare på tilläggets säkerhetsarkitektur för att se till att det ger rätt säkerhetsnivå med minimal risk för att något går sönder.

Nästa vecka ska vi titta på resultatet av en mer grundlig analys av vad som hände, men under tiden svarar jag gärna på frågor via e-post: [e-postskyddad]

Källa: linux.org.ru