Mozilla отозвала GPG-субключ, которым подписывала часть релизных файлов Firefox и Thunderbird. Причиной стал внутренний инцидент: незашифрованная копия секретного подписывающего материала по ошибке оказалась в закрытом репозитории GitHub. 10 августа компания перешла на новый субключ и добавила дополнительные меры защиты от повторения ситуации.
Публичной утечки Mozilla не обнаружила. Репозиторий был приватным, доступ к нему имела небольшая группа сотрудников компании. Каждый из них уже обладал разрешённым доступом к этому ключу через другие внутренние механизмы. Проверка доступных журналов не выявила обращений к ключу со стороны посторонних.
Mozilla всё равно решила считать прежний субключ потенциально раскрытым и вывести его из эксплуатации. Такая реакция оправдана для ключей подписи программного обеспечения: если секретная часть попадает к постороннему, он потенциально может создавать файлы с криптографически корректной подписью доверенного издателя. Для доставки поддельной сборки пользователю злоумышленнику всё равно потребовался бы отдельный канал распространения.
Большинству пользователей Firefox и Thunderbird ничего делать не нужно. Изменение заметят прежде всего те, кто вручную проверяет GPG-подписи загруженных файлов, а также часть пользователей официального RPM-репозитория Firefox.
Mozilla не меняла основную криптографическую идентичность, которой подписывающий ключ представлен пользователям. Компания выпустила новый signing subkey — подписывающий субключ — и отозвала предыдущий.
Отпечаток основного GPG-ключа остался прежним:
14F2 6682 D091 6CDD 81E3 7B6D 61B7 B526 D98F 0353
Новый подписывающий субключ имеет отпечаток:
827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3
Срок его действия заканчивается 5 августа 2028 года.
Долгоживущий основной ключ можно сохранить, заменив рабочий субключ, который непосредственно используется для подписи. Пользователю не приходится заново доверять совершенно другой основной криптографической идентичности Mozilla.
У компании уже была плановая смена субключа в апреле 2025 года. Тогда причиной становилось приближение срока его действия. Основной отпечаток 14F2…0353 тоже сохранялся, а менялся именно рабочий подписывающий субключ.
Нынешняя ротация внеплановая: прежний секретный материал оказался в репозитории в незашифрованном виде.
Инцидент касается не всех подписей, которые используются внутри Firefox. Mozilla перечисляет три основных типа файлов:
-
Linux-архивы Firefox и Thunderbird,
-
RPM-пакеты Firefox,
-
файлы с контрольными суммами релизов.
Thunderbird не распространяет официальные RPM-пакеты, поэтому отдельная процедура обновления RPM-ключа для него не требуется.
Документация инфраструктуры Firefox показывает несколько независимых форматов подписи. GPG создаёт отдельные .asc-подписи, Windows-компоненты используют Authenticode, приложения для macOS проходят собственную подпись и нотариальное заверение, а файлы обновлений Mozilla Archive — MAR — имеют отдельный механизм подписи.
Разработчик создаёт подпись с помощью секретного ключевого материала. Пользователь или пакетный менеджер проверяет её открытой частью ключа.
Если атакующий получает рабочий секретный ключ, он может изготовить другой файл и создать для него подпись, которую система, всё ещё доверяющая этому ключу, способна принять как корректную.
Именно здесь появляется риск атаки на цепочку поставок. Однако подпись не даёт злоумышленнику доступ к серверу загрузки Mozilla, CDN или компьютеру пользователя. Ему потребуется каким-либо способом доставить поддельный файл: разместить его на скомпрометированном ресурсе, убедить пользователя скачать его с другого сайта или получить контроль над дополнительным звеном распространения. В рассматриваемом случае нет ещё и подтверждения, что ключ вообще покинул доверенную группу Mozilla. Компания проверила доступные журналы и не обнаружила несанкционированного доступа.
Для Fedora 43 и более новых выпусков Mozilla не требует специального ручного вмешательства.
При следующем обновлении dnf должен получить обновлённый ключ и предложить его импортировать. Перед подтверждением Mozilla рекомендует сверить отпечаток нового субключа:
827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3
Официальный RPM-репозиторий Mozilla использует проверку подписи пакетов. В инструкции по установке Firefox параметр gpgcheck включён, а публичный ключ репозитория задаётся отдельно.
Поэтому смена подписывающего субключа непосредственно затрагивает доверие пакетного менеджера к новым RPM.
Fedora 42 и более ранние выпуски, а также указанные Mozilla системы RHEL, Rocky Linux и AlmaLinux сами заменить сохранённый ключ в этой ситуации не смогут.
Обновление может завершиться сообщением, что импорт нового ключа не помог, либо что уже установленные GPG-ключи репозитория не подходят для проверяемого пакета. Mozilla предлагает вручную удалить прежнюю запись ключа, импортировать актуальную и очистить кэш dnf.
Попытка просто импортировать новую версию поверх старой может внешне завершиться успешно, хотя запись фактически не обновится. Mozilla поэтому отдельно требует сначала удалить старый ключ.
Похожая ситуация возникает в openSUSE и других системах семейства SUSE. zypper самостоятельно старый ключ не заменит; возможны ошибки проверки подписи и NOKEY. Там также потребуется ручная ротация.
Новый подписывающий субключ используется не исключительно для Firefox. Mozilla пишет о Firefox и Thunderbird: им подписываются соответствующие Linux-архивы и файлы контрольных сумм.
Разница появляется только с RPM. Официальных RPM-пакетов Thunderbird Mozilla не предоставляет, поэтому пользователям почтового клиента не нужна описанная выше RPM-процедура.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
