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

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

{{VideoSection}}

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


== Thesis ==
* https://osday.ru/downloads/Kuznetsov.pdf

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

=== Взаимодействие с международным сообществом разработчиков ядра Linux ===
Ядро Linux является важной частью IT сферы нашего мира. Тысячи людей из разных стран вовлечены в его разработку. И так случается, что над исправлением одной и той же ошибки могут работать несколько команд. В нашей практике имеется аналогичный случай. После анализа срабатывания
«WARNING in vmci_datagram_dispatch», которое было обнаружено с помощью фаззинг- тестирования. Подготовленное нами исправление было отправлено в международное
сообщество согласно руководству по отправке изменений в ядро<ref>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</ref> 27 декабря 2023 года.

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

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

=== Взаимодействие с международным сообществом разработчиков прокси-сервер Squid ===
По результатам фаззинга прокси-сервера Squid была обнаружена уязвимость, эксплуатация которой могла привести к реализации атаки типа «отказ в обслуживании». В
соответствии с [https://www.squid-cache.org/Support/mailing-lists.html#squid-bugs процедурой ответственного разглашения Squid] и рекомендациями к [http://wiki.squid-cache.org/SquidFaq/BugReporting структуре отчета об ошибке] сведения об этом были направлены в закрытый список рассылки squid-bugs.

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

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

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

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


{{SlidesSection}}
[[File:Опыт взаимодействия с международным сообществом разработчиков при исправлении уязвимостей — ответственное разглашение, сроки исправления (OSDAY-2024).pdf|left|page=-|300px]]

{{----}}
[[File:{{#setmainimage:Опыт взаимодействия с международным сообществом разработчиков при исправлении уязвимостей — ответственное разглашение, сроки исправления (OSDAY-2024)!.jpg}}|center|640px]]
{{LinksSection}}

* 
<!-- <blockquote>[©]</blockquote> -->

<references/>

<!-- topub -->

[[Категория:OSDAY-2024]]
[[Категория:Draft]]