Что-то крупное на подходе: декабрьские патчи ядра с расплывчатыми описаниями

Несколько дней назад коллеги из kernel.org начали коммитить в Linux странные вещи. Патч KPTI - Kernel Page Table Isolation - появился в ветке для Linux 4.15, а затем пошли бэкпорты в стабильные 4.14, 4.9 и 4.4. Описания коммитов максимально невнятные, какие-то ссылки на «hardware bugs», без номера CVE, без конкретики. Такое бывает в двух случаях: либо разработчик просто не умеет писать commit message, либо идёт скоординированное эмбарго перед крупным раскрытием.

Второе куда вероятнее. KPTI - это принудительное разделение адресных пространств ядра и пользовательских процессов. Штука не новая концептуально, но раньше никто не спешил включать её по умолчанию - она бьёт по производительности. Резкий интерес к этой технике именно сейчас, в такой срочной манере, намекает на что-то серьёзное в самой архитектуре процессора, а не в конкретном коде.

Декабрьский Patch Tuesday добавил вопросов

Параллельно Microsoft в декабрьском Patch Tuesday выпустил обновления безопасности с формулировками в духе «устраняет уязвимость раскрытия информации». Категория есть, серьёзность есть, конкретного CVE и внятного описания нет. Для Microsoft это редкость - обычно бюллетени достаточно подробные. Когда формулировки настолько расплывчатые по нескольким связанным компонентам одновременно - это классическая картина скоординированного раскрытия, где часть вендоров уже патч выпустила, а детали публиковать пока нельзя.

AMD и Intel оба упоминались в обсуждениях ядерных патчей. По коду видно, что KPTI по умолчанию обходит AMD-процессоры - что-то специфичное для Intel. Ряд исследователей в открытых обсуждениях употребляет слово «спекулятивное исполнение» и намекает на side-channel атаки. Это нас и насторожило больше всего: side-channel в процессорной архитектуре - это не «нашли баг в коде», это фундаментально.

Как мы реагируем на неизвестное

Когда ещё непонятно, что именно раскроют и когда - паниковать рано, но готовиться можно. По опыту этого года - KRACK в октябре, Bad Rabbit в конце октября, Equifax в сентябре - экстренный патчинг работает лучше, если процедура написана заранее, а не придумывается в момент, когда все уже читают новости.

Что сделали сейчас:

• Обновили реестр систем с критическими сервисами у всех заказчиков: что крутится на физических серверах с Intel-процессорами, что на виртуалках поверх них, где живут гипервизоры. Это пригодится для приоритизации патчинга, если раскрытие окажется масштабным.
• Договорились о maintenance window - окна на вторую половину декабря и начало января. Праздничный период хорош тем, что нагрузка ниже, и перезагрузить серверы проще. Плохо тем, что людей меньше и поддержка у вендоров медленнее.
• Проверили статус автообновлений ядра на managed-хостах. В нескольких случаях обнаружили, что unattended-upgrades либо отключены, либо не включают пакет linux-image. Исправили.
• Поставили на мониторинг репозитории Red Hat и Ubuntu - security advisory должны появиться одновременно с официальным раскрытием.

Что настораживает в потенциальном масштабе

Если side-channel действительно затрагивает архитектуру Intel широко, то под ударом окажется не только физическое железо. Виртуализированные среды - а у наших заказчиков это большая часть продакшна - потенциально более уязвимы: гипервизор и гостевые системы делят одни и те же физические ядра, и если атакующий может читать память через спекулятивное исполнение, граница между VM и хостом становится вопросом.

Публичные облака - ещё интереснее. Там на одном физическом сервере могут жить виртуалки десятков разных клиентов. Мы пока не знаем CVE и не знаем реального вектора эксплуатации, но сама архитектура ставит вопрос: насколько изоляция по-прежнему работает как изоляция?

Вбрасывать конкретные оценки риска до раскрытия - плохая идея. Но готовить инфраструктуру к экстренному патчу ядра - абсолютно разумная. Ядерные патчи требуют перезагрузки, перезагрузка требует согласования, согласование занимает время. Лучше иметь окна согласованными заранее.

Что делает аудит в такие моменты

Неопределённость - не повод ждать. Для заказчиков, где мы ведём аудит безопасности, сейчас проверяем несколько вещей: насколько быстро они реально могут применить патч к ядру на продакшн-серверах, есть ли процедура экстренного обновления без четырёхнедельного цикла согласований, работает ли мониторинг security advisory от вендоров ОС.

Если раскрытие окажется масштабным - а все признаки на это указывают - разница между компанией, у которой процедура уже есть, и компанией, которая начнёт её писать после раскрытия, будет измеряться днями. Как показал Equifax, именно эти дни и стоят дороже всего.

Следим. Если что-то раскроется раньше ожидаемого - напишем сразу.