Проект curl стикається з фейковими звітами про вразливості, створеними ШІ
У тривожному загостренні ситуації з фальшивими звітами про вразливості, шановний проект з відкритим кодом curl, який святкує своє 25-річчя у 2023 році, повідомляє про сплеск подачі вразливостей, створених за допомогою штучного інтелекту. Це відволікає увагу розробників і ставить під загрозу цілісність процесу оцінки вразливостей.
Передумови: Універсальність curl та його модель безпеки
curl та його бібліотечний аналог libcurl щоденно обробляють мільярди транзакцій в Інтернеті, підтримуючи протоколи, такі як HTTP/1.1, HTTP/2, HTTP/3 через QUIC, FTP, SFTP, SMTP та інші. Проект дотримується суворої політики координованого розкриття вразливостей (CVD) і приймає звіти через HackerOne (з можливими винагородами), GitHub Issues та електронну пошту. Останні стабільні випуски (8.2.0 та 8.3.0) додали повну пріоритезацію потоків HTTP/3 та вдосконалене відновлення сесій TLS, що робить ретельний перегляд безпеки надзвичайно важливим.
Наплив фальшивих звітів на HackerOne
На LinkedIn засновник curl Даніель Стенберг попередив: “Ми досягли критичної межі. Нас фактично атакують DDoS. Якби була можливість, ми б стягували з них плату за цю втрату нашого часу.” Він зазначив, що тільки на початку травня 2025 року з’явилося чотири підозрілі звіти, кожен з яких був ідеально оформлений англійською мовою, містив марковані списки та пропозиції патчів, які не мали жодного відношення до кодової бази.
- Звіт “Експлуатація циклів залежностей потоків HTTP/3” стверджував про наявність умови гонки, що призводить до RCE.
- Запропоновані патчі стосувалися застарілого інструменту Python для демонстрацій, а не самого libcurl.
- Автори звітів не змогли відповісти на додаткові запитання про систему збірки curl, натомість вставляючи свій запит до штучного інтелекту, закінчуючи фразою: “і зробіть це звучати тривожно.”
Технічний аналіз фальшивого звіту
Найгірший звіт стверджував про нову експлуатацію в рамках PRIORITY у HTTP/3. Насправді реалізація curl (починаючи з версії 8.1.0) використовує контрольовані залежності потоків через ngtcp2 та забезпечує суворий контроль потоку і планування, щоб запобігти ін’єкціям або блокуванням. Зловмисна серверна конфігурація, надана автором звіту, не змогла скомпілюватися, посилаючись на неіснуючі функції (наприклад, curl_h3_handle_cycle()) та ігноруючи I/O-двигун curl, заснований на ASIO.
Ширший вплив на безпеку з відкритим кодом
curl не є єдиним проектом, що стикається з цією проблемою. Команди безпеки OpenSSL, libssh та GitLab також повідомили про збільшення кількості фальшивих звітів, створених штучним інтелектом, за останній квартал. У червні 2025 року головний спеціаліст з безпеки GitLab відзначив 300% зростання низькоякісних звітів, які були позначені їхньою системою оцінки на основі машинного навчання, що призвело до збільшення часу реагування на справжні подання.
Думки експертів і реакція спільноти
Сет Ларсон, розробник безпеки в Python Software Foundation, попереджає, що “цей тренд підриває довіру до програм винагород за вразливості та відволікає ресурси від справжніх проблем.” Тобіас Хелдт з компанії XOR, що спеціалізується на безпеці з відкритим кодом, підтримує ідею системи депозитів або застав: “Вимога невеликої плати забезпечує серйозність звітів і фільтрує автоматизовані подачі.”
Рекомендації та майбутні заходи
- Посилення фільтрів оцінки: автоматичне виявлення фраз, характерних для штучного інтелекту, і ненормальних маркованих шаблонів.
- Перевірка авторів звітів: вимога розкриття використаних інструментів (LLM, фуззери) та підтвердження ручної валідації.
- Заставні винагороди: невеликі повертані депозити для стримування подач з низькими зусиллями.
- Аудити спільноти: залучення волонтерів-експертів з безпеки для рецензування важливих звітів про вразливості.
Дивлячись у майбутнє: захист від шуму, спричиненого штучним інтелектом
Оскільки моделі великих мов стають більш доступними, проекти з відкритим кодом повинні адаптувати свої процеси управління вразливостями. Покращене маркування метаданих, класифікатори спаму на основі штучного інтелекту та спільні мережі репутації можуть допомогти відокремити сигнал від шуму. Для curl та його колег виклик очевидний: захистити обмежені ресурси розробників, зберігаючи при цьому відкритий підхід до звітності, який лежить в основі багаторічних покращень безпеки, ініційованих спільнотою.