Архив метки: Stenberg

Про уязвимости curl

4 комментария

Про уязвимости curl

Про уязвимости curl. 11-ое число пришло. Обещанные уязвимости в cURL и libcurl вышли. 🧐 Под "худшая уязвимость за длительное время" Daniel Stenberg видимо имел ввиду, что curl насколько безопасен, что даже худшие уязвимости там не особо впечатляют.

SOCKS5 heap buffer overflow (CVE-2023-38545), High. Уязвимость существует, если curl/libcurl используется вместе c SOCKS5 прокси-сервером (в режиме proxy-resolver-mode) и пользователь соединяется с зловредным HTTP сервером, который делает редирект на специальный URL. Происходящее переполнение буфера может привести к RCE. В общем, должны сойтись звёзды. 🤷‍♂️ Но если вы используете cURL/libcurl через SOCKS5 прокси, то обновляйтесь конечно.

Cookie injection with none file (CVE-2023-38546), Low. Злоумышленник может вставлять cookie в работающую программу с помощью libcurl, если соблюдается ряд условий. Как дальше использовать этот Cookie injection не очевидно, но если ваше приложение использует libcurl, то обновитесь.

Грядет опасная уязвимость cURL и libcurl (CVE-2023-38545)

1 комментарий

Грядет опасная уязвимость cURL и libcurl (CVE-2023-38545)

Грядет опасная уязвимость cURL и libcurl (CVE-2023-38545). Пока это всё, что известно. Daniel Stenberg, основатель и ведущий разработчик cURL и libcurl, собирается сообщить подробности 11 октября около 06:00 UTC вместе с релизом curl 8.4.0. Учитывая, как он не так давно возмущался сомнительной CVE-шкой, которую завели без его ведома, вряд ли он стал бы наводить панику из-за ерунды. Вполне возможно, что там будет уязвимость, которая существенно затронет софт, использующий libcurl. Так что ждём. 🙂

Довольно занимательный кейс с Integer overflow в curl (CVE-2020-19909)

1 комментарий

Довольно занимательный кейс с Integer overflow в curl (CVE-2020-19909)

Довольно занимательный кейс с Integer overflow в curl (CVE-2020-19909). Уязвимость недавно завели на NVD с описанием:

"Уязвимость целочисленного переполнения в tool_operate.c в curl 7.65.2 из-за большого значения задержки повторной попытки."

Другой бы вендор взял, да добавил эту уязвимость куда-нибудь в бюллетень как давно исправленную. Но разрабы curl-а вступили в борьбу. Основное, что они пишут: мы не знаем кто завел эту CVE, у нас был похожий кейс на hackerone, мы его пофиксили в 7.66.0 в Сентябре 2019, но это была просто бага, а не уязвимость (явно не CVSS 9.8), CVE не заводили.

Ну и основной посыл: это наш софт, и мы должны решать уязвимость это или нет.

Согласен ли я с этим? Ну, скорее нет. Как VM-щику мне бы хотелось в NVD видеть в базе уязвимостей ВСЕ уязвимости независимо от позиции вендора. Даже, если это приведёт к какому-то количеству фолсов и публичных диспутов. Вендоры и так сдерживают заведение CVE как могут.