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

Апрельский Linux Patch Wednesday

Апрельский Linux Patch Wednesday

Апрельский Linux Patch Wednesday. Всего уязвимостей: 251. 👌 164 в Linux Kernel. Уязвимостей с признаками эксплуатации вживую нет. Есть 7 уязвимостей с признаком наличия публичного эксплоита.

Для 2 уязвимостей есть подробно описанный эксплойт на GitHub. Обе они в первый раз исправлены в пакетах репозитория RedOS:

🔸 SQL injection - Exim (CVE-2025-26794)
🔸 Code Injection - MariaDB (CVE-2023-39593)

Для Memory Corruption - Mozilla Firefox (CVE-2025-3028), согласно NVD, эксплойт должен быть в багтреккере Mozilla, но к нему закрыт доступ. 🤷‍♂️

Для 4 уязвимостей есть публичные эксплоиты по данным БДУ ФСТЭК:

🔸 Information Disclosure - GLPI (CVE-2025-21626)
🔸 Security Feature Bypass - GLPI (CVE-2025-23024)
🔸 Denial of Service / Remote Code Execution - Perl (CVE-2024-56406)
🔸 Memory Corruption - Libsoup (CVE-2025-32050)

🗒 Полный отчёт Vulristics

Спросили сегодня как по инвентаризационным данным из GLPI получать cpe-идентификаторы для последующего детектирования уязвимостей

Спросили сегодня как по инвентаризационным данным из GLPI получать cpe-идентификаторы для последующего детектирования уязвимостей

Спросили сегодня как по инвентаризационным данным из GLPI получать cpe-идентификаторы для последующего детектирования уязвимостей. Сам я таким не занимался. Согласен, что получить из результатов инвентаризации cpe-идентификаторы это проблема. Но основная проблема в том, что получившиеся cpe-идентификаторы тоже достаточно бесполезны, т.к. если детектировать уязвимости с помощью них по данным из NVD, можно обнаружить, что они не всегда мапятся качественно и разбирать получившиеся false positive ошибки придется руками. Возьмем, например, CVE-2020-1102. Все версии sharepoint_server 2016 и 2019 всегда уязвимы что ли? Там патчи есть, их установку нужно учитывать.

Я скептически отношусь к разработке собственных универсальных утилит для детектирования уязвимостей (специализированных, например детектилки по бюллетеням конкретного Linux дистрибутива - это делать реально). Разработку универсальных средств детектирования лучше оставить VM-вендорам, у которых большой штат специалистов и они занимаются этим на фулл-тайм. А на стороне клиента лучше сосредоточиться на приоритизации уже продетектированных уязвимостей.