Технически подробности за наскоро деактивираните добавки в Firefox

Забележка на преводача: за удобство на читателите датите са представени по московско време

Наскоро пропуснахме момента за изтичане на един от сертификатите, използвани за подписване на добавки. Това доведе до деактивиране на добавки при потребителите. Сега, след като предимно проблема е решен, бих искал да разкажа за подробностите на случилото се и за извършената работа.

Контекст: добавки и подписи

Въпреки че много хора използват браузъра 'извън кутията', Firefox поддържа разширения, наречени 'добавки'. С тяхна помощ потребителите добавят различни възможности в браузъра. Съществуват над 15 хиляди добавки: от блокиране на реклами до управление на стотици табове.

Инсталираните добавки трябва да имат цифрова подпись, която защитава потребителите от злонамерени добавки и изисква минимална проверка на добавките от служителите на Mozilla. Ние въведохме това изискване през 2015 година, тъй като изпитвахме сериозни проблеми с злонамерени добавки.

Как работи: всяка копие на Firefox съдържа 'коренов сертификат'. Ключът от този 'корен' се съхранява в апаратния защитен модул (HSM), който няма мрежов достъп. На всеки няколко години с този ключ се подписва нов 'междинен сертификат', който се използва при подписване на добавките. Когато разработчикът изпрати добавка, ние създаваме временно 'краен сертификат' и го подписваме, използвайки междинния сертификат. След това краен сертификат подписва самата добавка. Схематично това изглежда така.

Обърнете внимание: всеки сертификат има 'субект' (кому е издаден сертификата) и 'издател' (кой е издал сертификата). В случая на кореновия сертификат 'субект' = 'издател', но за другите сертификати издателят е субектът на надзорния сертификат, издаден от него.

Важно: всяка добавка е подписана с уникален краен сертификат, но почти винаги тези крайни сертификати са подписани от един и същи междинен сертификат.

Забележка на автора: изключение са много стари добавки. Тогава са използвани различни междинни сертификати.

Този междинен сертификат предизвика проблеми: всеки сертификат е валиден в определен период. Преди или след този период сертификатът става невалиден и браузърът няма да използва добавки, подписани с този сертификат. За съжаление, срокът на валидност на междинния сертификат изтече на 4 май в 4 часа сутринта.

Последиците не се проявиха веднага. Firefox проверява подписите на инсталираните добавки не постоянно, а приблизително на всеки 24 часа, като времето за проверка е индивидуално за всеки потребител. В резултат на това, при някои хора проблемите възникнаха веднага, а при други много по-късно. За първи път научихме за проблема точно в момента, когато изтече срокът на валидност на сертификата, и веднага започнахме да търсим решение.

Намаляване на щетите

След като осъзнахме какво се е случило, се опитахме да предотвратим влошаването на ситуацията.

Първо, спряхме да приемаме и подписваме нови добавки. Няма смисъл да използваме изтекъл сертификат за това. Оглядайки се назад, бих казал, че можеше да оставим всичко както е. Сега приемането на добавки е възстановено.

Второ, незабавно разпратехме корекция, която предотврати ежедневната проверка на подписи. По този начин спасихме потребителите, за които браузърът през последните 24 часа все още не е успял да провери добавките. Сега тази корекция е отзована, необходимостта от нея вече не съществува.

Паралелна работа

Теоретично, решението на проблема изглежда просто: създаваме нов валиден междинен сертификат и презаписваме всяка добавка. За съжаление, това няма да сработи:

• не можем бързо да презапишем 15 хиляди добавки наведнъж, системата не е предназначена за такава натовареност
• след като подпишем добавките, обновените версии трябва да бъдат доставени на потребителите. Повечето добавки се инсталират от сървърите на Mozilla, така че през следващите 24 часа Firefox ще намери актуализации, но някои разработчици разпространяват подписани добавки чрез външни канали, така че потребителите ще трябва да обновяват такива добавки ръчно

Вместо това се опитахме да разработим такава корекция, която да достигне до всички потребители, като не изисква (или почти не изисква) действия от тяхна страна.

Доста бързо стигнахме до две основни стратегии, които използвахме паралелно:

• Актуализирайте Firefox, за да промените периода на действие на сертификата. Това ще накара съществуващите добавки да заработят отново, но ще изисква издаване и доставка на нова версия на Firefox.
• Създайте валиден сертификат и по някакъв начин убедете Firefox да го приеме вместо съществуващия, чийто срок на действие е изтекъл.

Решихме първо да използваме първия вариант, който изглеждаше напълно работещ. В края на деня издадохме второ коригиране (нов сертификат), за което ще говорим по-късно.

Смяна на сертификата

Както споменах по-горе, беше необходимо:

• да създадем нов валиден сертификат
• да го инсталираме дистанционно в Firefox

За да разберем защо това ще сработи, нека по-подробно разгледаме процеса на проверка на добавката. Самата добавка се предлага под формата на набор от файлове, включително веригата сертификати, използвани за подписване. В резултат на това добавката може да бъде проверена, ако на браузъра е известен кореновият сертификат, който е вграден в Firefox по време на компилацията. Но, както вече знаем, междинният сертификат е изтекъл, така че не е възможно да се провери добавката.

Когато Firefox се опитва да провери добавката, той не се ограничава до използването на сертификатите, съдържащи се в самата добавка. Вместо това браузърът се опитва да създаде валидна верига от сертификати, започвайки с крайния сертификат и продължава, докато не достигне корена. На първото ниво започваме с крайния сертификат и след това намираме сертификат, чийто субект е издателят на крайния сертификат (тоест междинният сертификат). Обикновено този междинен сертификат се предлага заедно с добавката, но в тази роля също може да бъде всеки сертификат от хранилището на браузъра. Ако успеем да добавим дистанционно нов валиден сертификат в хранилището на сертификати, Firefox ще се опита да го използва. Ситуацията преди и след инсталирането на новия сертификат.

След инсталирането на новия сертификат, Firefox има две опции при проверка на веригата на сертификатите: да използва стария невалиден сертификат (който няма да работи), или новия валиден (който ще работи). Важно е, че новият сертификат съдържа същото име на субекта и публичния ключ, както и стария сертификат, следователно неговият подпис на крайните сертификати ще бъде валиден. Firefox е достатъчно умел, за да опита и двете опции, докато не намери работещата, така че добавките отново ще станат проверени. Обърнете внимание, това е същата логика, която използваме за проверка на TLS сертификати.

Бележка на автора: читателите, запознати с WebPKI, ще забележат, че точно така работят крос-сертификатите.

Най-удивителното в това решение е, че не изисква повторно подписване на съществуващите добавки. След като браузърът получи новия сертификат, всички добавки отново ще заработят. Остава трудността да се достави новия сертификат на потребителите (автоматично и отдалечено), както и да се накара Firefox да прехвърли контрола върху деактивираните добавки.

Normandy и системата за проучвания

По ирония на съдбата, този проблем се решава от специално добавка, наречена «системна». За да провеждаме проучвания, разработихме система, наречена Normandy, която доставя проучвания на потребителите. Тези проучвания се изпълняват автоматично в браузъра и имат разширен достъп до вътрешните API интерфейси на Firefox. Проучванията могат да добавят нови сертификати в хранилището на сертификати.

Бележка на автора: не добавяме сертификат с никакви специални привилегии; той е подписан от кореновия сертификат, така че Firefox му вярва. Просто го добавяме в пул от сертификати, които могат да бъдат използвани от браузъра.

Така че решението е да създадем проучване:

• което инсталира на потребителите новия сертификат, създаден от нас
• което принуждава браузъра да проверява отново деактивираните добавки, за да работят отново

«Но изчакай», ще кажете, «добавките не работят, как да стартираме системната добавка?». Ще я подпишем с новия сертификат!

Събираме всичко заедно… защо отнема толкова време?

И така, планът: да се издаде нов сертификат за замяна на стария, да се създаде системно добавление и да се инсталира на потребителите чрез Normandy. Проблемите, както казах, започнаха на 4 май в 4:00, а вече в 12:44 същия ден, по-малко от 9 часа по-късно, изпратихме корекция до Normandy. Необходимо беше още 6-12 часа, за да достигне до всички потребители. Вече не е лошо, но потребителите в Twitter питат защо не можем да действаме по-бързо.

На първо място, отне време да се издаде нов междинен сертификат. Както споменах по-горе, ключът за коренния сертификат се съхранява автономно в хардуерен модул за сигурност. Това е добре от гледна точка на сигурността, тъй като коренът се използва много рядко и трябва да бъде надеждно защитен, но е малко неудобно, когато трябва спешно да се подпише нов сертификат. Един от нашите инженери трябваше да отиде до хранилището HSM. След това имаше неуспешни опити да се издаде правилният сертификат, а всеки опит струваше един или два часа за тестване.

На второ място, разработването на системното добавление отне известно време. Концептуално това е много просто, но дори простите програми изискват внимание. Искахме да се уверим, че няма да направим ситуацията още по-лоша. Изследването трябва да бъде тествано преди изпращането на потребителите. Освен това, добавлението трябва да бъде подписано, но нашата система за подписване на добавления беше деактивирана и трябваше да намерим обходен път.

Накрая, след като подготвихме изследването за изпращане, разгръщането отне време. Уеб браузърът проверява за актуализации на Normandy на всеки 6 часа. Не всички компютри са постоянно включени и свързани с интернет, така че е необходимо време, за да се разпространи корекцията сред потребителите.

Финални стъпки

Изследването трябва да реши проблема за повечето потребители, но не е налично за всички. Нужен е специален подход за някои потребители:

• потребители, които са деактивирали изследвания или телеметрия
• потребители на Android версията (Fennec), където изследванията не се поддържат изобщо
• потребители на кастомни версии на Firefox ESR в предприятия, където не може да бъде активирана телеметрията
• потребители, които използват MitM прокси, тъй като нашата система за инсталиране на добавки използва съвпадение на ключове (key pinning), което не работи с такива проксита
• потребители на остарели версии на Firefox, които не поддържат изследвания

Ние не можем да направим нищо за последната категория потребители — те все пак трябва да обновят до нова версия на Firefox, тъй като остарелите имат сериозни неразрешени уязвимости. Знаем, че някои хора остават на старите версии на Firefox, защото искат да стартират стари добавки, но много от старите добавки вече са пренасочени за новите версии на браузъра. За другите потребители сме разработили пач, който ще инсталира нов сертификат. Той беше публикуван като бъгфикс релийз (забележка на преводача: Firefox 66.0.5), така че хората ще го получат — вероятно вече са го получили — през обичайния канал за обновление. Ако използвате персонализирана версия на Firefox ESR, свържете се с вашия поддържащ екип.

Разбираме, че всичко това не е идеално. В някои случаи потребителите загубиха данни от добавките (например данните на добавката Multi-Account Containers).

Тази страничен ефект не можеше да бъде избегнат, но смятаме, че в краткосрочен план избрахме най-доброто решение за повечето потребители. В дългосрочен план ще търсим други, по-усъвършенствани архитектурни подходи.

Уроки

На първо място, нашият екип свърши невероятна работа, създавайки и изпращайки корекция по-малко от 12 часа след откритие на проблема. Като човек, който присъстваше на срещите, мога да кажа, че в тази сложна ситуация хората работеха много усърдно и малко време беше загубено напразно.

Очевидно всичко това изобщо не трябваше да се случва. Ясно е, че е необходимо да коригираме нашите процеси, за да намалим вероятността от подобни инциденти и да улесним поправянето на последствията.

Следната седмица ќе објавиме официјален post-mortem и список на промени што планираме да ги направиме. Досега, ќе споделам свои мисли. Прво, мора да има подобар начин за следење на состојбата на она што е потенцијална бомба со одложено активирање. Треба да сме сигурни дека нема да се најдеме во ситуација кога некоја од нив ненадејно ќе експлодира. Сè уште работиме на деталите, но најмалку, потребно е да се води евиденција на сите слични работи.

Второ, ни е потребен механизам за брзо испорака на ажурирања до корисниците, дури и кога – особено кога – сè друго не функционира. Беше одлично што успеавме да ја користиме системот за 'истражувања', но тоа е несовршен инструмент и има некои непосакувани несакани ефекти. Конкретно, знаеме дека многу корисници имаат вклучено автоматско ажурирање, но би претпочитале да не учествуваат во истражувањата (признавам, и јас ги исклучив!). Во исто време, ни е потребен начин да испратиме ажурирања до корисниците, но, каква и да е внатрешната техничка реализација, корисниците треба да имаат можност да се запишат за ажурирања (вклучувајќи итни исправки), но да се одбие од сè друго. Исто така, каналот за ажурирање треба да биде поодговорен од сега. Дури и на 6 мај, имаше корисници кои не ја искористија ни исправката, ниту новата верзија. Веќе работиме на овој проблем, но она што се случи покажа колку е важен.

На крај, ќе погледнеме во архитектурата на безбедноста на додатоците за да се увериме дека обезбедува соодветно ниво на безбедност со минимален ризик од разбивање на нешто.

Следната недела ќе ги разгледаме резултатите од подеталниот анализа на она што се случи, а за сега ќе се радувам да одговорам на прашања преку e-mail: ekr-blog@mozilla.com

Източник: linux.org.ru