Как черные шляпы пользуются открытостью open source ПО

ПО с открытым кодом (и особенно со свободными лицензиями) стало фундаментом многих (или даже большинства) информационных систем. Однако открытость кода, баг-трекера, списков рассылок и публичный способ передачи патчей/PR используются злоумышленниками.

1. Делают то же самое, что и white hats, например анализом кода и фаззингом (fuzzing), при наличии исходных кодов это делать легче, чем бинарники. Многие OSS-проекты не занимаются этим сами (fuzzing-ом), за них это делают бигтехи, белые и черные шляпы

2. Пользуются ситуацией, связанной с так называемыми silent patches (см. 1, 2). Это когда уязвимость исправляется, релиз выпускается, но CVE не создается и в changelog тоже не говорится про исправление уязвимостей. По второй ссылке описано как это можно детектировать с хорошей точностью с помощью LLM

3. Непрерывный анализ коммитов и PR (по аналогии с п.2), зачастую коммит/PR появляется раньше, чем создана запись CVE и/или выпущен релиз. В описании коммита может быть как явно указано что-то типа «fix segfault» (что большой долей вероятности будет являться уязвимостью), либо чуть более завуалировано, например «add additional check for array index». В любом случае, даже простенькая LLM классифирует такой коммит как потенциальную уязвимость для последующего анализа

4. Анализ сообщений баг-трекера (mailing list), а иногда (если можно заполучить контактные данные) и попытки связаться с автором бага вне трекера, чтобы заполучить дополнительную информацию, например, coredump

5. От выпуска исправления до попадания этого релиза (или его бэкпорта) в рамках дистрибутива ОС проходит время, пока мейнтенеры дистрибутива интегрируют исправление. Но если какое-то другое ПО «таскает» проблемное ПО(например библиотеку) с собой (в рамках контейнера, статически линкует/как-то еще интегрирует в себя), то надо ждать пока зависимое ПО произведет обновление проблемной зависимости

6. Злоумышленники могут втереться в доверие, стать мейнтейнерами проекта. В мире OSS, зачастую, разработчики одного проекта не имеют никакого представления о своих «коллегах» с правом на коммит в master (main). Пример с xz уже стал каноническим для этого сценария

Каких-то универсальных способов решения этих проблем нет, но вот о чем стоит задуматься: когда вы затаскиваете в свой проект библиотеку или стороннее ПО типа БД с открытым кодом:

• есть ли вообще у проекта CI, есть ли тесты, есть ли статический анализ кода (и динамический если применимо), занимаются ли разработчики фаззингом. Могут быть сторонние CI/фаззеры, наиболее значимыми OSS-проектами занимается Google в рамках проекта OSS-Fuzz

• публикуются ли CVE (почитать changelog и сравнить с CVE, иногда сразу понятно, что это игнорируется)

• почитать CVE (если их добросовестно публикуют), возможно вместо бесконечных buffer-overflow и use-after-free вы решите, что стоит выбрать ПО на другом языке, где целые классы уязвимостей исключены (с библиотеками конечно сложнее если вы сами разрабатываете на таком языке)

• как вы будете доставлять обновления ваших зависимостей себе (если через дистрибутив ОС, то как быстро мейнтенеры дистрибутива применяют патчи безопасности)

• есть ли «покровители» у проекта в виде организаций или это тот самый проект из мема «a project some random person in Nebraska has been thanklessly maintaining since 2003» (случай с «Heartbleed» в OpenSSL навсегда попала в историю)

• если вы нашли какое-то стороннее ПО с открытым кодом, а оно выглядит не сильно популярным сомнительным по многим критериям, но именно оно подходит вам лучше всего, то стоит задуматься о том, чтобы вложиться в него — дописать тесты, натравить на него анализаторы и привести его к такому «стандарту качества», который вы определили для своего

P.S. Данная заметка призывает не отказываться от OSS в своих проектах, а тщательно анализировать свои зависимости и вкладываться в те, которые вы используете, а в случае коммерческой разработки закладывать это на ресурсы.