Как поссорились Иван Интелович с Иваном Опёнковичем

Многие слышали историю о том, как OpenBSD «отлучили» от информации об уязвимостях Meltdown и Spectre.

В середине 2017 года Мэти Ванхоф (Mathy Vanhoef), молодой и при этом уже известный в определённых кругах специалист в области безопасности, уже несколько лет занимавшийся вопросами защиты беспроводных сетей IEEE 802.11 (Wi-Fi), последовательно обнаруживает ряд проблем в реализации протоколов WPA и WPA2, разной степени серьёзности. Самая крупная из проблем позднее получит персональное имя — KRACK.

Будучи добропорядочным исследователем, Ванхоф извещает разработчиков реализаций WPA о найденных проблемах с тем, чтобы каждый смог подготовить исправления. В том числе, 15 июля 2017 года такое извещение было отправлено приватно разработчикам OpenBSD. Выработанное решение было согласовано с Ванхофом и 30 августа, по согласованию с ним же, внесено в кодовую базу OpenBSD под видом минорного исправления. Подобная политика позволяет выступать open source-проектам на равных с разработчиками пропиетарных ОС, которые могут не боясь огласки выпускать обновления безопасности.

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

В это же время ряд исследователей обнаружил уязвимость в микропроцессорах Intel, позволявшую медленно, но верно получать по косвенному каналу содержимое произвольных участков адресного пространства текущего процесса (включая содержимое ядра операционной системы). К делу подключились специалисты Intel а позднее, когда стала очевидна универсальность подхода, и других производителей микропроцессоров. Когда стало понятно, что данную уязвимость невозможно закрыть одним только изменением микрокода, к работе стали подключать разработчиков операционных систем. Однако в свете упомянутых выше событий, связанных с KRACK, компания Intel (и, возможно, другие заинтересованные лица) настояла на невключении проекта OpenBSD как неблагонадёжного партнёра.

Изначально эмбарго планировалось снять в середине января, однако допущенная в LKML утечка вынудила сдвинуть сроки. Фактически, повторилась описанная выше ситуация, но теперь уже с Linux: журналисты из The Register (и не только они) обратили внимание на поток серьёзных патчей, в результате чего анонс был срочно перенесён на 4-е января. Именно тогда разработчики OpenBSD (как и DragonFly BSD? Кто ещё? % ) узнали о проблеме — наравне с широкой общественностью. Из-за крайне высокой сложности проблемы работа над исправлением ситуации заняла не один месяц. В ходе работы по конструированию обходных путей для Meltdown/Spectre были решены следующие задачи:

• разделение адресных пространств ядра и приложения;
• модификация компиляторов для генерации защищающего от Meltdown/Specre кода;
• реализация инфраструктуры обновления микрокода ЦП Intel.

Однако на этом дело не закончилось: с каждым месяцем исследователи находили всё новые уязвимости в ЦП. И далеко не все из них разделяли мнение о том, что OpenBSD надо «наказать». Например, Бен Грас (Ben Gras) из VUSec по собственной воле поделился с разработчиками OpenBSD подробностями найденной им уязвимости TLBleed, позволяющей организовать утечку секретных ключей за счёт эксплуатации особенностей Intel Hyper Threading (на процессорах с одновременной многопоточностью других производителей организовать эффективную атаку оказалось затруднительно). Ещё более интересная ситуация сложилась с уязвимостью LazyFP: до разработчиков OpenBSD дошли слухи о наличии уязвимости, связанной с сохранением состояния сопроцессора. По этим скудным обрывкам был создан и закоммичен патч, о котором Тео де Раадт, лидер проекта, рассказал на конференции BSDCan. Через пять часов после этого Колин Персиваль, бывший FreeBSD security officer, смог создать рабочий эксплоит — в результате проект OpenBSD, не нарушив эмбарго, таки поспособствовал досрочному анонсу уязвимости (полностью подробности на момент написания этих строк по-прежнему не раскрыты).

Таким образом можно констатировать, что изоляция проекта OpenBSD не удалась, и следует ожидать изменения позиции Intel (и других производителей, разделявших отношение Intel к OpenBSD) по вопросам предварительного информирования об уязвимости.