Кратко

  • FORT 1.6.8, выпущенный 31 мая, ограничивает ссылки RRDP между источниками и загружает снимок до удаления локальной рабочей области. Удаление и разбор теперь зависят от признака изменения содержимого.
  • Быстрый путь кеша по-прежнему возвращает записанный результат попытки. Это не повторная проверка наличия файла; совпавший хеш также не определяет право на пересборку или решение маршрутизатора.

Майское исправление FORT меняет не математику хеша, а то, как клиент распоряжается результатом загрузки. Такое различие важно: настоящие данные с правильной контрольной суммой ещё не гарантируют безопасного контекста обработки.

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

FORT — проект LACNIC и NIC.MX. Официальное уведомление относит проблему общего кеша снимков к высокой категории серьёзности, указывает версии до 1.6.7 включительно как затронутые и 1.6.8 как исправленную. Это исследование опубликованных источников от 14 сентября. Здесь нет воспроизведения атаки, оценки числа установок или сообщения о новом сентябрьском выпуске.

Что перестало выполняться безусловно

В исходном коде RRDP, закреплённом на выпуске 1.6.7, handle_snapshot сначала вызывает delete_rpp и удаляет локальную рабочую область точки публикации. Затем следует cache_download. Успешный возврат приводит к parse_snapshot без условия, что именно этот вызов получил новое содержимое.

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

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

В той же версии разбор метаданных уведомления отвергает ссылки на снимки и дельты с другим источником. Ограничить, какие ресурсы уведомление может вовлечь, и ограничить, когда заменяется локальная область, — разные меры. Называть обе «усиленной проверкой хеша» неточно.

Кеш всё ещё помнит попытку

В коде кеша 1.6.8 сохраняется быстрый возврат прошлого результата. Сначала получается загружаемый URI в контексте якоря доверия. Затем запись ищется по локальному пути, который возвращает uri_get_local: это видимый ключ хеш-таблицы, а не буквально один глобальный HTTPS-адрес.

Если попытка достаточно новая относительно запуска кеша, возвращается её записанный результат. Перед этим возвратом функция заново не проверяет, существует ли нужный файл физически.

Другие пути проверяют файлы: cache_check и очистка записей с отсутствующими файлами. Из наблюдения за быстрым путём нельзя сделать вывод, будто FORT никогда не смотрит на файловую систему. Но нельзя и приписать каждому сохранённому успеху свежую проверку наличия.

Оставшийся быстрый путь не доказывает, что опубликованная атака работает в исправленной версии. Исправление ограничивает использование результата обработчиком снимка. Это объяснение ремонта, не обнаруженный способ его обойти.

Загрузить раньше — не значит проверить раньше

Исправленная parse_snapshot сверяет ожидаемый хеш до разбора XML. В исследовании не утверждается, что снимок с неверным хешем принимается.

Есть, однако, другая граница гарантии. В ветви changed обработчик удаляет рабочую область, а затем вызывает parse_snapshot, где и проверяется хеш. В этой функции загрузка до удаления не равна проверке до удаления. Одна такая последовательность не доказывает полную транзакцию, всегда сохраняющую последнее исправное состояние.

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

Совпавший хеш связывает байты с ожидаемым значением. Он не заменяет проверку подписей и ресурсов RPKI, не выдаёт разрешение на пересборку области другого репозитория и не задаёт политику маршрутизатора.

Один источник не означает одну машину

RFC 9674, опубликованный в декабре 2024 года, обновляет RFC 8182. Правило одного источника требует одинаковых схемы, узла и порта для ссылок и запрещает переадресацию к другому источнику. Это не требование одной компании, учётной записи или физического сервера.

За нужным источником может работать CDN. Здесь подтверждены изученные проверки ссылок на снимки и дельты, а не проведён полный аудит HTTP-переадресации или всего соответствия стандарту.

Сохранение кеша имеет сильное обоснование. Множество клиентов обращается к меньшему числу репозиториев. Повторять каждую передачу или запрещать распределённую доставку означало бы увеличивать нагрузку. Разумная цель — различать память загрузки и разрешённую конкретную пересборку, а не противопоставлять производительность безопасности вообще.

Источники