Мнения о том, как лучше всего раскрывать уязвимости безопасности, расходятся, но в linux сообществе существует общий консенсус в отношении того, что уязвимости действительно должны быть обнародованы в какой-то момент. То, что происходит между обнаружением уязвимости и ее раскрытием, может быть более спорным. Недавняя дискуссия об обработке уязвимостей ядра привела к изменению политики списка рассылки linux-distros.
Существует два списка рассылки, которые обычно используются для обсуждения уязвимостей в сообществе Linux; они не ограничиваются проблемами ядра. Первый из них, linux-distros, представляет собой закрытый список, который используется для координации реагирования на непубличные ошибки безопасности. Второй, oss-security, представляет собой рассылку, которая используется, среди прочего, для публичного раскрытия уязвимостей. Обе рассылки управляются Александром Песляком.
Одно из правил рассылки linux-distros требует публичного раскрытия всех уязвимостей в течение относительно короткого периода времени. Это правило существует для того, чтобы гарантировать, что компании не скрывают уязвимости, независимо от того, насколько глупыми они бы не были. Другое правило рассылки, однако, гласит, что уязвимости, которые уже являются общедоступными, не должны обсуждаться в linux-distros; все обсуждение публичных уязвимостей относится к oss-security. Следование этим правилам часто оказывалось сложной задачей, особенно при работе с уязвимостями ядра; см. статью 2021 года в качестве недавнего примера.
В середине мая Песляк написал сообщение в рассылку oss-security в поисках решения для продолжающегося несоответствия между политиками списка и тем, как проект ядра ведёт разработку. Основная проблема заключается в том, как проблемы безопасности часто решаются в сообществе ядра:
Для разработчиков ядра Linux стало привычкой сначала публиковать патчи, исправляющие уязвимость, публично, но без указания на их критичность для безопасности, а затем работать над их слиянием в различные ветки и надеяться, что уязвимость не будет предана огласке в течение некоторого времени.
Такие патчи, как правило, выглядят так. Согласно политике списка рассылки linux-distros, эта публичная публикация исправления делает конкретную уязвимость непригодной для обсуждения там — уязвимость уже раскрыта. Но разработчики ядра по-прежнему хотят иметь способ обсудить реальную уязвимость, которая еще не раскрыта, в закрытом режиме и координировать распространения патчей пользователям. Это не может быть сделано в рассылке oss-security, которая является общедоступной, и это не может быть сделано в linux-distros, потому что публикация патча рассматривается как раскрытие уязвимости.
Все чаще, по словам Песляка, политика linux-distros просто игнорируется, когда дело доходит до уязвимостей ядра. И он спрашивает, что следует делать с этой проблемой. Одним из вариантов, по его словам, было бы продолжать игнорировать правила рассылки, когда уязвимость, для которой доступен общедоступный патч, появляется там. Другие варианты включают строгое соблюдение политики (и, таким образом, полное исключение уязвимостей ядра из рассылки), изменение политики рассылки или даже просто полное закрытие рассылки.
Как и следовало ожидать, было высказано множество мнений, хотя никто, не выступил за то, чтобы просто закрыть рассылку. Доминирующая точка зрения, была в пользу корректировки правил рассылки, чтобы лучше соответствовать процессу разработки ядра.
Джейсон Доненфельд предложил продолжить строго применять это правило, так как разработчики ядра мало заинтересованы в чем-либо, кроме исправления ошибки. Как выразился Доненфельд: разработчики ядра мало заинтересованы в «игре безопасности» и вряд ли начнут в нее играть. Грег Кроа-Хартман описал еще одну причину, по которой проект ядра обрабатывает исправления безопасности так, как он это делает:
Как известно, существуют разные «уровни» злоумышленников. Существует огромный диапазон от «запустить metasploit, который я только что скачал» до «посмотреть на этот патч ядра и выяснить, как взламывать системы, которые ещё не обновились». Добавив небольшой промежуток времени между публикацией патча и объявлением о уязвимости позволяет сообществу, которое работает в открытую, получить достаточно времени для проверки и тестирования, поскольку наша инфраструктура тестирования, которая НЕ является общедоступной, довольно ограничена, а возможности код-ревью ограничены, учитывая огромный диапазон необходимых разработчиков для проведения этого ревью.
Эта задержка может позволить пользователям получить исправление в своей системе, прежде чем пакет «metasploit» будет обновлен для её атаки, что уменьшает количество уязвимых систем. Да, это не решает проблему «читателей всех коммитов», но я не знаю, что мы действительно можем с этим сделать, кроме перехода на модель разработки с закрытым исходным кодом, что в целом не очень хорошая идея.
Проблема код-ревью патчей уязвимостей довольно велика. Исправления безопасности не застрахованы от болезней, которые мешают разработке программного обеспечения в целом; они могут легко добавлять новые ошибки (в том числе связанные с безопасностью), вызывать регрессии и т.д. Как и любые другие изменения, они выигрывают от тщательного ревью (и обширного тестирования) перед применением. Существуют ограничения на то, какая часть этого ревью и тестирования может произойти без публикации патча в открытом доступе.
Преимущества сокрытия проблемы безопасности, которую исправляет конкретный патч, могут быть не совсем ясны. Это вполне может уменьшить количество случайных атак со стороны скрипт-кидди, но, как отметил Кроа-Хартман, оно мало что делает для защиты от злоумышленников, которые просматривают логи коммитов в git с целью поиска уязвимостей. Тем не менее, есть разработчики и компании, которые видят веские причины держать проблемы безопасности в тайне, по крайней мере, в течение короткого периода.
Учитывая предполагаемую ценность публикации патчей без явного раскрытия основной проблемы безопасности, Кроа-Хартман сказал, что лучшее, что можно сделать, это изменить политику списка рассылки, чтобы разрешить такие сообщения. Он высказал мысль о том, что другие крупные проекты также могли бы выиграть от такой политики. Песляк не был уверен, что эти проекты, большинство из которых вообще не используют linux-distros, будут заинтересованы, но он, в конце концов, решил изменить политику linux-distros, чтобы приспособиться к способу разработки ядра. Проблемы с публичным исправлением сами считаются публичными, говорится в новом правиле, за исключением случаев, когда они не являются:
Могут быть исключения из этого, например, если общедоступное исправление не выглядит так, как будто оно предназначено для исправления уязвимости и раскрывать это публично сразу по каким-то причинам считается нежелательным. В частности, мы предоставляем такие исключения для уязвимостей ядра Linux, которые одновременно или совсем недавно исправлялись командой безопасности ядра Linux.
Учитывая отсутствие последующего обсуждения, представляется вероятным, что это изменение приемлемо для членов списка в целом. Между тем, Вегард Носсум в данный момент работает над изменениями в документации ядра, чтобы сделать правила для сообщения об уязвимостях более четкими. Ничто из этого окончательно не положит конец дискуссиям вокруг правил обнародования информации об уязвимостях, раскрытия информации и списков рассылки, но, если повезет, это заставит все работать немного более гладко, чем сейчас.
