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

Прожектор по ИБ, выпуск №6 (08.10.2023)

Прожектор по ИБ, выпуск №6 (08.10.2023). Записали очередной эпизод. В основном мы говорили про уязвимости прошлой недели.

Мы это:

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

00:00 Здороваемся, смотрим статистику по просмотрам предыдущего выпуска
02:18 Саша вышел на работу в Positive Technologies и чем же он там будет заниматься
04:50 RCE без аутентификации в почтовом сервере Exim (CVE-2023-42115)
08:16 SSRF/RCE в TorchServe (CVE-2023-43654, CVE-2022-1471), ShellTorch
12:05 В Cisco Emergency Responder нашли root-овые учётки с захардкоженными паролями (CVE-2023-20101)
16:44 Новый криптографический протокол аутентификации OpenPubkey
17:56 EoP или обход аутентификации в Atlassian Confluence (CVE-2023-22515)
23:42 Грядет опасная уязвимость cURL и libcurl (CVE-2023-38545)
27:07 Новая bug bounty программа Минцифры
30:32 Система бронирования "Леонардо" вновь подверглась DDOS-атаке из-за рубежа
35:22 Экосистема Xiaomi вышла из строя по всей России
36:38 Qualys-ы наресерчили EoP/LPE уязвимость во всех Linux-дистрибах, а конкретно в glibc (CVE-2023-4911)
39:19 XSpider-у 25 лет. Ровно как и всему современному Vulnerability Management-у. Обсуждаем в какую сторону развивается VM.
46:42 Прощание от Mr. X

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

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

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

Прожектор по ИБ, выпуск №1 (01.09.2023)

Прожектор по ИБ, выпуск №1 (01.09.2023). Вроде в прошлый раз неплохо получилось, записали ещё один эпизод тем же составом:

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

01:13 Публичные эксплоиты для уязвимостей Juniper и WinRAR
08:34 Брешь протокола BGP может привести к длительным сбоям в работе интернета
12:45 Подозрительные изменения в британском Investigatory Powers Act 2016 (IPA)
21:13 НеУязвимость curl
27:18 Google удалила пиратские URL из личных сохранённых ссылок пользователей
34:17 Взлом национального центра готовности к инцидентам и стратегии кибербезопасности Японии
36:59 Блокировка ПО со стороны Microsoft стала бы благом?

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

Довольно занимательный кейс с 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 как могут.