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

Obs. av översättaren: för bekvämlighetens skull anges datumen i Moskvatid.

Nyligen missade vi tidsfristen för en av de certifikat som används för att signera tillägg. Det ledde till att tilläggen stängdes av för användare. Nu när problemet till stor del har åtgärdats, skulle jag vilja berätta om de detaljer som inträffade och det arbete som utförts.

Bakgrund: tillägg och signaturer

Även om många använder webbläsaren "som den är", stödjer Firefox tillägg, kallade "extensions". Med deras hjälp kan användare lägga till olika funktioner i webbläsaren. Det finns över 15 000 tillägg: från annonsblockering till hantering av hundratals flikar.

Installerade tillägg måste ha digital signatur, som skyddar användare från skadliga tillägg och kräver en minimal kontroll av tillägg av Mozilla-anställda. 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 detta "rot" förvaras i en hårdvarusäkerhetsmodul (HSM), som inte har nätverksåtkomst. Vart flera år signeras ett nytt "intermediärt certifikat" med denna nyckel, som används vid signering av tillägg. När en utvecklare skickar ett tillägg skapar vi ett temporärt "slutcertifikat" och signerar det med det intermediära certifikatet. Detta slutcertifikat signerar sedan själva tillägget. Schematisk ser det ut så här.

Observera: varje certifikat har ett "subjekt" (till vem certifikatet utfärdats) och en "utfärdare" (vem som utfärdat certifikatet). I fallet med ett rotcertifikat är "subjekt" = "utfärdare", men för andra certifikat är utfärdaren av certifikatet subjektet av det överordnade certifikatet som det har signerats av.

En viktig punkt: varje tillägg är signerat med ett unikt slutcertifikat, men nästan alltid är dessa slutcertifikat signerade med samma intermediära certifikat.

Författarens anmärkning: undantaget är mycket gamla tillägg. Då användes olika intermediära certifikat.

Det här mellanliggande certifikat orsakade problem: varje certifikat är giltigt under en viss period. Innan eller efter denna period är certifikatet ogiltigt, och webbläsaren kommer inte att använda tillägg signerade med detta certifikat. Tyvärr gick giltighetstiden för det mellanliggande certifikatet ut den 4 maj klockan 04:00.

Konsekvenserna visade sig inte genast. Firefox kontrollerar signaturer av installerade tillägg inte kontinuerligt, utan ungefär var 24:e timme, där kontrolltidpunkten är individuell för varje användare. Som ett resultat uppstod problem för vissa människor omedelbart, medan andra drabbades mycket senare. Vi fick kännedom om problemet ungefär när certifikatets giltighetstid gick ut och började genast leta efter en lösning.

Minska skadorna

Så snart vi insåg vad som hänt försökte vi förhindra att situationen försämrades.

För det första slutade vi att ta emot och signera nya tillägg. Det är meningslöst att använda ett utgånget certifikat för detta ändamål. I efterhand skulle jag säga att vi kunde ha låtit allt förbli som det var. Nu har vi återupptagit mottagningen av tillägg.

För det andra skickade vi omedelbart ut en åtgärd som förhindrade den dagliga signaturkontrollen. På så sätt räddade vi de användare vars webbläsare inte hade hunnit kontrollera tilläggen under de senaste 24 timmarna. Denna åtgärd har nu dragits tillbaka, eftersom den inte längre är nödvändig.

Parallell drift

Teoretiskt sett verkar lösningen enkel: vi skapar ett nytt giltigt mellanliggande certifikat och omsignerar varje tillägg. Tyvärr fungerar inte det:

• vi kan inte snabbt omsignera 15 000 tillägg på en gång, systemet är inte byggt för en sådan belastning
• efter att vi signerat tilläggen måste de uppdaterade versionerna levereras till användarna. De flesta tillägg installeras från Mozillas servrar, så under de kommande 24 timmarna kommer Firefox att hitta uppdateringar, men vissa utvecklare distribuerar signerade tillägg via externa kanaler, vilket innebär att användarna skulle behöva uppdatera sådana tillägg manuellt

Istället försökte vi utveckla en åtgärd som skulle nå alla användare utan att kräva (eller nästan inte kräva) några åtgärder från deras sida.

Vi kom ganska snabbt fram till två huvudstrategier som vi använde parallellt:

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

Vi beslutade att först använda det första alternativet, vilket verkade vara fullt fungerande. I slutet av dagen släppte vi också den andra fixen (det nya certifikatet), som vi kommer att diskutera senare.

Byt certifikat

Som jag nämnde tidigare, krävdes det:

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

För att förstå varför detta kommer att fungera, låt oss ta en närmare titt på processen för att verifiera ett tillägg. Själva tillägget levereras som en uppsättning filer, inklusive certifikatkedjan som används för signering. Därför kan tillägget verifieras om webbläsaren känner till rotcertifikatet, som byggs in i Firefox under bygget. Men som vi redan vet är det mellanliggande certifikatet utgånget, så det är omöjligt att verifiera tillägget.

När Firefox försöker verifiera ett tillägg begränsar den sig inte till certifikaten som finns inuti tillägget självt. Istället försöker webbläsaren skapa en giltig certifikatkedja, som börjar med det slutliga certifikatet och fortsätter tills den når roten. På första nivån börjar vi med det slutliga certifikatet och hittar sedan certifikatet vars subjekt är utgivaren av det slutliga certifikatet (dvs. det mellanliggande certifikatet). Oftast levereras detta mellanliggande certifikat tillsammans med tillägget, men vilken certifikat från webbläsarens lagring kan också fungera i denna roll. Om vi kan lägga till ett nytt giltigt certifikat i certifikats förvar på distans, kommer Firefox att försöka använda det. Situationen före och efter installationen av det nya certifikatet.

Efter installationen av det nya certifikatet kommer Firefox att ha två alternativ vid verifiering av certifikatkedjan: att använda det gamla ogiltiga certifikatet (som inte fungerar) eller det nya giltiga certifikatet (som fungerar). Det är viktigt att det nya certifikatet innehåller samma ämnesnamn och den offentliga nyckeln som det gamla certifikatet, så dess signatur på det slutliga certifikatet kommer att vara giltig. Firefox är tillräckligt smart för att försöka båda alternativen tills det hittar en fungerande, så tillägg kommer att bli verifierade igen. Observera att detta är samma logik som vi använder för att verifiera TLS-certifikat.

Författarens anmärkning: läsare med kunskap om WebPKI kommer att märka att korscertifikat fungerar på exakt samma sätt.

Det mest fantastiska med denna lösning är att det inte kräver omsignering av befintliga tillägg. Så snart webbläsaren får det nya certifikatet, kommer alla tillägg att fungera igen. Det återstår en utmaning att distribuera det nya certifikatet till användarna (automatiskt och på distans) samt att få Firefox att verifiera de inaktiverade tilläggen igen.

Normandy och forskningssystemet

Ironiskt nog löses detta problem av ett speciellt tillägg, kallat "systemtillägget". För att genomföra studier har vi utvecklat ett system som heter Normandy, som levererar studier till användarna. Dessa studier genomförs automatiskt i webbläsaren och har utökat tillgång till interna API:er i Firefox. Studier kan lägga till nya certifikat i certifikatförrådet.

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

Lösningen är alltså att skapa en undersökning:

• som installerar det nya certifikatet vi har skapat för användarna
• som får webbläsaren att verifiera de inaktiverade tilläggen så att de fungerar igen

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

Låt oss samla allt... varför tar det så lång tid?

Så planen är att lansera ett nytt certifikat för att ersätta det gamla, skapa ett systemtillägg och installera det för användarna via Normandy. Problemen, som jag nämnde, började den 4 maj klockan 04:00, och redan klockan 12:44 samma dag, mindre än 9 timmar senare, skickade vi en lösning till Normandy. Det tog ytterligare 6-12 timmar för det att nå alla användare. Redan ganska bra, men användare på Twitter undrar varför vi inte kunde agera snabbare.

För det första tog det tid att utfärda ett nytt internt certifikat. Som jag nämnde tidigare förvaras nyckeln till det rotcertifikatet offline i en hårdvarusäkerhetsmodul. Detta är bra ur säkerhetssynpunkt, eftersom roten används mycket sällan och måste skyddas ordentligt, men det är lite besvärligt när man plötsligt behöver signera ett nytt certifikat. En av våra ingenjörer behövde åka till HSM-lagret. Sedan var det flera misslyckade försök att utfärda det korrekta certifikatet, och varje försök tog en till två timmar som gick åt till testning.

För det andra tog det tid att utveckla systemtillägget. Konceptuellt är det mycket enkelt, men även enkla program kräver noggrannhet. Vi ville försäkra oss om att vi inte skulle göra situationen värre. Forskningen behövde testas innan den skickades till användarna. Dessutom måste tillägget signeras, men vårt system för att signera tillägg var avstängt, så vi var tvungna att hitta en alternativ lösning.

Slutligen, efter att vi hade förberett forskningen för utskick, krävdes det tid för distribution. Webbläsaren kontrollerar för uppdateringar av Normandy var sjätte timme. Inte alla datorer är ständigt påslagna och anslutna till internet, så det krävs tid för lösningen att sprida sig bland användarna.

Sista stegen

Forskningen bör rätta till problemet för de flesta användare, men den är inte tillgänglig för alla. Vissa användare kräver en speciell åtgärd:

• användare som har inaktiverat forskning eller telemetri
• användare av Android-versionen (Fennec), där forskning inte stöds överhuvudtaget
• användare av anpassade versioner av Firefox ESR på företag där telemetri inte kan aktiveras
• användare som sitter bakom en MitM-proxy, eftersom vårt tilläggsinstallationssystem använder nyckelbindning (key pinning), som inte fungerar med sådana proxy
• användare av föråldrade versioner av Firefox som inte stödjer forskning

Vi kan inte göra någonting åt den sista kategorin användare — de bör ändå uppdatera till den nya versionen av Firefox, eftersom de föråldrade har allvarliga oåtgärdade sårbarheter. Vi vet att vissa människor stannar kvar på gamla versioner av Firefox eftersom de vill köra gamla tillägg, men många av de gamla tilläggen har redan portats till nya versioner av webbläsaren. För andra användare har vi utvecklat en patch som kommer att installera ett nytt certifikat. Det har släppts som en buggfixrelease (översättarens kommentar: Firefox 66.0.5), så människor kommer att få det — troligtvis redan fått det — via den vanliga uppdateringskanalen. Om du använder en anpassad version av Firefox ESR, kontakta din huvudansvarige.

Vi förstår att allt detta inte är perfekt. I vissa fall har användare förlorat tilläggens data (t.ex. tilläggens data Multi-Account Containers).

Detta bieffekt kunde inte undvikas, men vi anser att vi på kort sikt valde den bästa lösningen för de flesta användare. På lång sikt kommer vi att söka efter andra, mer avancerade arkitektoniska tillvägagångssätt.

Lektioner

För det första, vårt team gjorde ett fantastiskt jobb med att skapa och skicka en fix mindre än 12 timmar efter att problemet upptäcktes. Som någon som var närvarande vid mötena kan jag säga att i den här svåra situationen arbetade folk mycket hårt och nästan ingen tid gick till spillo.

Det är uppenbart att allt detta överhuvudtaget inte borde ha inträffat. Det är uppenbart värt att justera våra processer för att minska sannolikheten för liknande incidenter och underlätta korrigering av konsekvenserna.

Nästa vecka kommer vi att publicera en officiell post-mortem och en lista över ändringar som vi planerar att göra. Tills dess delar jag gärna med mig av mina tankar. För det första behöver vi ett bättre sätt att spåra tillståndet av vad som kan vara en potentiell tickande bomb. Vi måste vara säkra på att vi inte hamnar i en situation där någon av dem plötsligt slår till. Vi arbetar fortfarande på detaljerna, men minst sagt krävs en inventering av alla sådana saker.

För det andra behövs en mekanism för snabb leverans av uppdateringar till användarna, även när - särskilt när - allt annat går ner. Det var fantastiskt att vi kunde använda forskningssystemet, men det är ett ofullkomligt verktyg och har vissa oönskade biverkningar. Vi vet till exempel att många användare har automatiska uppdateringar aktiverade, men de skulle föredra att inte delta i forskningen (jag måste erkänna att jag också har stängt av det!). Samtidigt behöver vi ett sätt att skicka uppdateringar till användarna, men oavsett hur den interna tekniska implementationen är, måste användarna kunna prenumerera på uppdateringar (inklusive akuta korrigeringar) men avstå från allt annat. Dessutom måste uppdateringskanalen vara mer responsiv än vad den är nu. Även den 6 maj fanns det fortfarande användare som inte hade utnyttjat vare sig korrigeringen eller den nya versionen. Det har redan arbetats med detta problem, men det som hänt har visat hur viktigt det är.

Till sist kommer vi att se över säkerhetsarkitekturen för tillägg för att säkerställa att den erbjuder en adekvat säkerhetsnivå med minimal risk för att något går sönder.

Nästa vecka kommer vi att granska resultaten av en mer grundlig analys av händelsen, men tills dess är jag glad att svara på frågor via e-post: ekr-blog@mozilla.com

Källa: linux.org.ru