Опыт взаимодействия с международным сообществом разработчиков при исправлении уязвимостей — ответственное разглашение, сроки исправления (OSDAY-2024) — различия между версиями

;{{SpeakerInfo}}: 
* {{Speaker|Александр Кузнецов }}
* {{Speaker|Егор Игнатов}}
<blockquote>
При разработке дистрибутивов операционных систем необходимо уделять внимание исследованию безопасности свободного программного обеспечения (СПО), лежащего в их основе. В ходе этого исследования нередко обнаруживаются новые, неизвестные международному сообществу уязвимости. Однако даже после того, как уязвимость в СПО была обнаружена, и для нее было разработано исправление, непростой задачей может оказаться его донесение до международного сообщества разработчиков. В докладе на трех примерах будет рассмотрен опыт взаимодействия с международным сообществом разработчиков ядра Linux, библиотеки Libvirt и кэширующего прокси-сервера Squid при исправлении уязвимостей, а также предложены рекомендации по организации данного взаимодействия.
</blockquote>

{{VideoSection}}
{{vimeoembed|982140545|800|450}}
<!-- {{youtubelink|}} -->|tWgdMNBSQ1w}}


== Thesis ==

Текущая версия на 23:14, 2 августа 2024

Докладчик

• Александр Кузнецов
• 
  Егор Игнатов

При разработке дистрибутивов операционных систем необходимо уделять внимание исследованию безопасности свободного программного обеспечения (СПО), лежащего в их основе. В ходе этого исследования нередко обнаруживаются новые, неизвестные международному сообществу уязвимости. Однако даже после того, как уязвимость в СПО была обнаружена, и для нее было разработано исправление, непростой задачей может оказаться его донесение до международного сообщества разработчиков. В докладе на трех примерах будет рассмотрен опыт взаимодействия с международным сообществом разработчиков ядра Linux, библиотеки Libvirt и кэширующего прокси-сервера Squid при исправлении уязвимостей, а также предложены рекомендации по организации данного взаимодействия.

Видео

on youtube

Thesis

• https://osday.ru/downloads/Kuznetsov.pdf

Введение

После того, как уязвимость в свободном программном обеспечении была обнаружена и было разработано исправление, непростой задачей может оказаться его донесение до международного сообщества разработчиков. В данной работе на трех примерах рассмотрен опыт взаимодействия с международным сообществом разработчиков ядра Linux, библиотеки Libvirt и кэширующего прокси-сервера Squid, а также предложены рекомендации по организации данного взаимодействия.

Взаимодействие с международным сообществом разработчиков ядра Linux

Ядро Linux является важной частью IT сферы нашего мира. Тысячи людей из разных стран вовлечены в его разработку. И так случается, что над исправлением одной и той же ошибки могут работать несколько команд. В нашей практике имеется аналогичный случай. После анализа срабатывания «WARNING in vmci_datagram_dispatch», которое было обнаружено с помощью фаззинг- тестирования. Подготовленное нами исправление было отправлено в международное сообщество согласно руководству по отправке изменений в ядро^[1] 27 декабря 2023 года.

Чуть позже выяснилось, что при отправке в список получателей не был добавлен почтовый адрес рассылки linux-kernel@vger.kernel.org, а сопровождающие подсистемы просто проигнорировали данное письмо. 10 января 2024 года мы повторно отправили исправления уже с добавленным адресом рассылки. Однако сопровождающий стабильных веток ядра Linux ответил, что исправление этой ошибки уже было зарегистрировано ранее, 05 января, компанией Oracle. Предложенные ими изменения, который аналогичны нашим, в последствие приняли в исходный код ядра.

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

Взаимодействие с международным сообществом разработчиков прокси-сервер Squid

По результатам фаззинга прокси-сервера Squid была обнаружена уязвимость, эксплуатация которой могла привести к реализации атаки типа «отказ в обслуживании». В соответствии с процедурой ответственного разглашения Squid и рекомендациями к структуре отчета об ошибке сведения об этом были направлены в закрытый список рассылки squid-bugs.

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

Взаимодействие с международным сообществом разработчиков библиотеки Libvirt.

По результатам фаззинга была обнаружена уязвимость, эксплуатация которой могла привести к реализации атаки типа «отказ в обслуживании».

В соответствии с securityprocess.html процедурой ответственного разглашения libvirt и опираясь на опыт сообщения об уязвимости в Squid, а также Google Project Zero vulnerability disclosure FAQ было направлено письмо, устанавливающее период эмбарго на неразглашение сведений об уязвимости в течение 90 дней. Уязвимости был присвоен индекс CVE-2024-1441 и информация о ней была публично опубликована через 23 дня после направления письма, с рекомендацией от разработчиков устанавливать более сжатые сроки эмбарго от 14 дней и меньше. Следующая аналогичная уязвимость была направлена с эмбарго в 14 дней, а публично опубликована через 21 день с двукратным продлением сроков эмбарго. Продление сроков эмбарго происходило по согласованию, тем не менее в течение 15-го и 21-го дня с момента направления письма подтверждения продления эмбарго еще не произошло, но срок первичного эмбарго уже истек. В связи с этим было принято решение о необходимости заранее определять порядок действий в случае истечения эмбарго, но при этом продлевать его при положительной реакции со стороны сообщества разработчиков.

Заключение

Таким образом, сформированы следующие рекомендации по выстраиванию взаимодействия с международным сообществом разработчиков в случае отправки информации об обнаруженной уязвимости:

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

Презентация

Примечания и ссылки

1. ↑ Submitting patches: the essential guide to getting your code into the kernel // The Linux Kernel documentation [Электронный ресурс]. URL: https://www.kernel.org/doc/html/latest/process/submitting-patches.html