Кратко

  • В мае 2008 года Debian исправил специфическое для своего пакета OpenSSL изменение генератора случайных чисел. Обновление защищало будущую генерацию, но не меняло ключи SSH, OpenVPN, DNSSEC и X.509, созданные с сентября 2006 года и уже перенесённые на другие системы.
  • Полное восстановление требовало раздельных действий: установить происхождение ключа, блокировать известные слабые семейства, создать замену при исправной энтропии, подтвердить её распространение, удалить старое разрешение или отозвать сертификат и доказать отказ на стороне каждого существенного доверяющего узла.

Патч не обладал памятью

DSA-1571-1 от 13 мая 2008 года сообщил, что генератор случайных чисел в пакете OpenSSL для Debian предсказуем. После обновления следующий ключ создавался исправным кодом. Ключ, созданный вчера, не менялся.

Слабый ключ не обязан выглядеть повреждённым. Его формат корректен, открытая и закрытая части согласованы, подпись SSH проверяется. Сертификат X.509 может иметь действительную подпись издателя и неистёкший срок. Дефект находится в невидимой истории создания: секрет был выбран из пространства, намного меньшего, чем предполагала криптографическая схема.

Поэтому Debian рекомендовал заново создать весь криптографический материал, выпущенный затронутыми версиями начиная с 0.9.8c-1. Для DSA предупреждение было шире: даже изначально сильный ключ мог раскрыться, если использовался на затронутой машине и подпись получила предсказуемое секретное случайное значение.

Ubuntu правильно очертил периметр. Debian-производные системы содержали дефектный генератор. Система другой семьи могла косвенно пострадать, если импортировала слабый ключ и продолжала его принимать. Граница пакета не совпадала с границей полномочий ключа.

Малое множество под видом большого ключевого пространства

Debian bug #363516 начался в апреле 2006 года с сообщений Valgrind о чтении неинициализированной памяти генератором OpenSSL. Обсуждение искало способ убрать диагностический шум. Позднейшая запись уточнила, что реально компилируемое уязвимое изменение появилось в 0.9.8c-1, когда изменённый md_rand.c переместили в используемый путь сборки.

Документация Debian SSLkeys описывает практический эффект. Сломанный генератор фактически зависел от идентификатора процесса. При 32 767 возможных потоках в каждой из трёх архитектурных групп модель даёт 98 301 поток. Для распространённых типов и размеров можно было заранее вычислить кандидатов и по наблюдаемому открытому ключу найти соответствующий закрытый.

Это не общее число слабых ключей и не статистика атак. Приложения по-разному обращались к библиотеке; менялись алгоритмы, размеры и архитектуры; списки блокировки имели границы. Число показывает другое: открытый ключ, безопасный именно потому, что закрытую половину нельзя практически восстановить, стал индексом в перебираемом каталоге.

Ключ сохранил внешнюю форму редкости, утратив её реальную основу.

Debian отдельно остановил доверие

Вскоре после уведомления проект Debian отключил вход по открытым ключам SSH на своей инфраструктуре. Автоматические передачи, сборки и административные процессы должны были подтвердить безопасность ключей или заменить их.

Если бы обновление библиотеки отзывалo старые ключи, локальная остановка не потребовалась бы. Debian исправил источник, а затем отдельно воспользовался полномочием доверяющей стороны.

DSA-1576-1 добавил openssh-blacklist и ssh-vulnkey. Обновлённый сервер мог по возможности отвергать известные слабые пользовательские ключи. Ключи хоста можно было пересоздать с подтверждением администратора. Но распространение замены шло в разных направлениях.

При смене ключа хоста клиент показывал предупреждение о смене удалённой идентичности. Законное восстановление и атака посредника выглядят здесь одинаково. Новый отпечаток требовалось проверить через независимый надёжный канал, а не массово отключать предупреждение.

Новый пользовательский ключ, наоборот, надо было внести на каждый сервер и удалить старую строку из каждого authorized_keys. Простое добавление замены создавало второй способ входа и оставляло угадываемый ключ действующим.

Пакет, blacklist, новый ключ, канал проверки отпечатка и удалённое разрешение имели разных владельцев. Ни один шаг не мог закрыть всю цепь.

Список блокировки был ограниченным правом отказа

Малое множество кандидатов позволило перечислить известные слабые открытые ключи. Получающее приложение сравнивало предъявленный ключ с corpus и локально отказывало. Опубликованное доказательство превращалось в исполняемое правило.

Но публикация списка не выключала ключ удалённо. Требовались установленный пакет, подходящий parser, поддерживаемый тип и размер, а также выполненная ветвь отказа. Debian писал «где возможно». Результат Unknown (no blacklist information) у Ubuntu означал отсутствие информации, а не безопасность.

DSA-1576-2 исправил ранний пробел. Строки authorized_keys, начинавшиеся с опций — например, принудительной команды, — могли не попасть в отчёт. Сервер продолжал принимать ключ. Позднейшие обновления Ubuntu расширили проверку X.509, запросов сертификатов, модулей и дополнительных размеров RSA.

Blacklist оставался полезным: даже никогда не уязвимая машина могла отвергнуть импортированный известный ключ и не допустить его повторной установки. Но отрицательный результат был не сильнее версии парсера, корпуса и покрытого формата.

Для каждого протокола — своё место отзыва

CERT перечислил SSH, OpenVPN, DNSSEC и X.509. Общий источник не создал общей команды отзыва.

Полномочие пользовательского SSH-ключа находилось в удалённых файлах разрешений. Завершение доказывалось неудачным входом старого ключа на каждом важном сервере. Доверие к ключу хоста SSH находилось у клиентов и зависело от подтверждения нового отпечатка.

Общий секрет OpenVPN надо было синхронно заменить на всех сторонах. При сертификатной схеме требовались новая выдача и отказ от старого сертификата. USN-612-3 подчёркивал, что материал, созданный для других систем, следует найти и заменить именно там.

В X.509 выпуск нового ключа и сертификата не стирал старый. Издатель публиковал отзыв, служба устанавливала новую цепочку, клиент получал свежий статус. RFC 5280 описывает сертификаты и CRL, но не заставляет каждое установленное приложение немедленно проверить обновление.

В DNSSEC ключ мог попасть в подписанную делегацию и кэши. В автоматизации он мог жить в образах, резервных копиях, устройствах и системах партнёров. Удаление исходного файла не меняло их решений.

Единицей ремонта была родословная учётных данных: создание, копии, сертификаты, разрешения и все точки, которые продолжали говорить «да».

Математически верно, операционно неправомерно

SSH проверяет владение секретом, соответствующим открытому ключу. Он не проверяет, знает ли секрет только законный владелец. Атакующий, вычисливший слабую закрытую половину, мог представить математически корректное доказательство.

Техническая валидность пережила основание легитимного доступа.

Опубликованные заметки Lu Heng о running code полезны как аналитическая рамка, но не являются источником хронологии Debian. Advisory, патч, blacklist и статус сертификата — данные и правила. Отказ становится реальным там, где SSH-сервер, VPN-партнёр или PKI-клиент выполняет правило. Debian управлял пакетами и своими системами, а не каждым удалённым файлом авторизации.

И наоборот, никогда не уязвимая платформа оставалась участником инцидента, если принимала импортированный слабый ключ. Практический контроль находился у локальной доверяющей стороны, вместе с обязанностью сохранить проверяемое право отказа.

Четыре реестра вместо одного процента

Реестр создания связывает отпечаток с датой, пакетом, библиотекой, приложением, архитектурой, алгоритмом и размером. Реестр распространения учитывает закрытые копии, сертификаты, серверы, authorized_keys, known_hosts, VPN-партнёров, образы, резервные копии и внешние организации.

Реестр замены соединяет старый и новый отпечаток, канал подтверждения, владельца и срок. Реестр отказа доказывает, что старый ключ больше не проходит, старый сертификат отвергается проверенными клиентами, а исключения имеют владельца и дату окончания.

Доля патчей измеряет начало. Остаток старых полномочий измеряет завершение.

Границы доказательств

Официальные источники не дают полного числа слабых ключей и успешных атак. 98 301 поток — ограниченная модель. Unknown не доказывает ни безопасность, ни слабость. Резервное копирование и неверные часы меняют даты файлов. GnuPG и GnuTLS использовали иные источники. Автоматическая смена ключа хоста зависела от пакета и решения администратора. Перевыпуск не доказывает проверку отзыва всеми клиентами.

Достоверный вывод точнее: исправленный генератор защитил будущее; старые ключи сохраняли власть до отказа в каждой точке принятия.

Источники