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

Поделюсь своими грустными мыслями по поводу RedOS в связи с Linux Patch Wednesday

Добавить комментарий

Поделюсь своими грустными мыслями по поводу RedOS в связи с Linux Patch Wednesday

Поделюсь своими грустными мыслями по поводу RedOS в связи с Linux Patch Wednesday.

🔹 С одной стороны, РЕД СОФТ большие молодцы, так как добавляют в своими репозитории пакеты прикладного софта, которых нет у других Linux-вендоров, и поддерживают детекты уязвимостей для них в OVAL-контенте. Причём добавляют новые сборки пакетов с исправленными CVE-шками очень оперативно.

🔹 С другой стороны, они, видимо, не особо смотрят какие именно CVE-шки исправил вендор софта и относятся ли эти CVE-шки к Linux-у. 🤷‍♂️ Поэтому возникают казусы, которые видны, например, в августовском Linux Patch Wednesday.

Что там в ТОП-е?

🔻 Remote Code Execution - PHP (CVE-2024-4577). Которая связана с функцией преобразования кодировки Best-Fit в операционной системе Windows. 😏 Исправлена в RedOS.

🔻 Remote Code Execution - Mozilla Firefox (CVE-2024-2605). "An attacker could have leveraged the Windows Error Reporter to run arbitrary code". 😌 Исправлена в RedOS.

🔻 Command Injection - Rust Standard Library (CVE-2024-24576). "who invoke batch files on Windows with untrusted arguments". 😣 Исправлена в RedOS.

То есть отчёт по Linux Patch Wednesday замусоривается уязвимостями, которые эксплуатируются только в Windows.

Как на моём уровне с этим бороться непонятно. Моя концепция, которая лежит в основе Linux Patch Wednesday, "Linux-овые уязвимости - это уязвимости, которые исправляют Linux-овые вендоры" в этом случае трещит по швам. А отказываться от RedOS как от источника данных тоже не хотелось бы (см. первый пункт про то, что РЕД СОФТ молодцы). Остаётся только закрывать на часть уязвимостей глаза и страдать. 🫣😔

Другие Linux-вендоры бюллетени (и OVAL-definition-ы) об исправлении виндовых уязвимостей не выпускают. Они обычно имеют страницу по каждой CVE. И если CVE не аффектит Linux-овую версию софта, то в бюллетень она не попадает. Было бы здорово, чтобы RedOS также эту практику пересмотрели.

Если у кого-то из подписчиков есть выход на людей, которые бюллетенями безопасности и OVAL-контентом в РЕД СОФТ занимаются, скиньте им, пожалуйста, этот пост. Буду рад познакомиться и пообщаться.

Августовский Linux Patch Wednesday

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

Августовский Linux Patch Wednesday

Августовский Linux Patch Wednesday. 658 уязвимостей. Из них 380 в Linux Kernel. Около 10 c признаками эксплуатации вживую. Можно выделить:

🔻 Уязвимости IT Asset Management системы GLPI: AuthBypass (CVE-2023-35939, CVE-2023-35940) и Code Injection (CVE-2023-35924, CVE-2023-36808, CVE-2024-27096, CVE-2024-29889). Фиксы в RedOS.
🔻 InfDisclosure - Minio (CVE-2023-28432). Старая и трендовая, но также фиксы засветились только в RedOS.
🔻 DoS - PHP (CVE-2024-2757). Если бы я учитывал бюллетени Fedora или Alpine, то эта ушла бы в более ранний LPW. 🤔 В 2DO.

Около 30 без эксплуатации вживую, но с эксплоитами. Можно выделить:

🔸 Command Injection - Apache HTTP Server (CVE-2024-40898)
🔸 AuthBypass - Apache HTTP Server (CVE-2024-40725)
🔸 AuthBypass - Neat VNC (CVE-2024-42458)
🔸 RCE - Calibre (CVE-2024-6782); да, та самая софтина для электронных книжек 🙂

🗒 Отчёт Vulristics по августовскому Linux Patch Wednesday

Июльский Linux Patch Wednesday

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

Июльский Linux Patch Wednesday

Июльский Linux Patch Wednesday. Всего 705 уязвимостей, из них 498 в Linux Kernel. С признаком эксплуатации вживую уязвимостей пока нет, у 11 есть признак наличия публичного эксплоита:

🔻 В абсолютном топе RCE - OpenSSH "regreSSHion" (CVE-2024-6387) со множеством вариантов эксплоитов на GitHub. Среди них могут быть и зловредные фейки (❗️). Здесь же упомяну похожую уязвимость RCE - OpenSSH (CVE-2024-6409), для которой эксплоитов пока нет.
🔻 В паблике есть ссылки на PoC-и для DoS уязвимостей Suricata (CVE-2024-38536) и QEMU (CVE-2024-3567).

Согласно БДУ, существуют публичные эксплоиты для:

🔸 AuthBypass - RADIUS Protocol (CVE-2024-3596), её фиксили и в июльском MSPT
🔸 Security Feature Bypass - Exim (CVE-2024-39929) - обход блокировок по mime_filename, а также в Nextcloud (CVE-2024-22403) - вечные OAuth коды
🔸 DoS - OpenTelemetry (CVE-2023-45142)
🔸 Memory Corruption - 7-Zip (CVE-2023-52168)

🗒 Отчёт Vulristics по июльскому Linux Patch Wednesday

Обновил июньский Linux Patch Wednesday и перевыпустил отчёт Vulristics

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

Обновил июньский Linux Patch Wednesday и перевыпустил отчёт Vulristics

Обновил июньский Linux Patch Wednesday и перевыпустил отчёт Vulristics. Общее количество уязвимостей снизилось с 1053 до 1040. Видимо для них стали доступны более ранние таймстемпы фиксов. Но уязвимости с признаком эксплуатации вживую и с публичным эксплоитом это не зацепило, они остались теми же.

🗒 Отчёт Vulristics по июньскому Linux Patch Wednesday

Linux Patch Wednesday: вот где этот майский пик!

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

Linux Patch Wednesday: вот где этот майский пик!

Linux Patch Wednesday: вот где этот майский пик! 🤦‍♂️ Также об июньском Linux Patch Wednesday. Помните, я в посте про майский Linux Patch Wednesday радовался, что, несмотря на введение правила по Unknown датам, пик в мае был незначительный. Хотя "32 406 oval definition-ов без даты получили номинальную дату 2024-05-15". Оказалось пик не был виден из-за ошибки в коде. Ба-дум-тсс! 🥸🤷‍♂️

То, что не все CVE-шки у меня попадаются в LPW бюллетени, несмотря на введение номинальных дат, я заметил на примере громкой уязвимости Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086), которой действительно нигде не было. Подебажил функцию распределения по бюллетеням, добавил тесты. Добился того, что все 38 362 CVE-шки из Linux-ового OVAL-контента действительно раскидываются по бюллетеням. Включая CVE-2024-1086. Вот она в феврале:

$ grep "CVE-2024-1086"  bulletins/*
bulletins/2024-02-21.json:        "CVE-2024-1086": [
bulletins/2024-02-21.json:                "title": "CVE-2024-1086 linux",
bulletins/2024-02-21.json:                "title": "CVE-2024-1086 linux",
bulletins/2024-02-21.json:                "title": "CVE-2024-1086 linux",

Ну и пик в мае действительно есть. Да ещё какой! 11 476 CVE! 😱 Настолько много, что я перегенерил Vulristics отчёт для него только с использованием 2 источников: Vulners и БДУ. И даже из Vulners данные подгружались не быстро. В отчёте 77 уязвимостей с признаком активной эксплуатации вживую и 1 404 уязвимости с эксплоитами, но без признаков активной эксплуатации. Т.к. по больше части это уязвимости старые, для которых просто не было понятно когда именно они были исправлены, например, Remote Code Execution - Apache HTTP Server (CVE-2021-42013), я не буду подробно их разбирать - кому интересно смотрите отчёт. Но обратите внимание, что размер отчёта очень большой.

🗒 Отчёт Vulristics по майскому Linux Patch Wednesday (31.3 мб.)

Что касается июньского Linux Patch Wedneday, который финализировался 19 июня, то там 1040 уязвимости. Тоже довольно много. Почему так? С одной стороны правило по Unknown датам добавило 977 Debian-овских OVAL дефинишенов без даты. Не 30к, как в мае, но тоже значительно. Из 1040 уязвимостей 854 это уязвимости Linux Kernel. Причём, довольно много "старых" идентификаторов уязвимостей, но заведенных в 2024 году. Например, CVE-2021-47489 с NVD Published Date 05/22/2024. 🤔 Что-то странное творит CNA Linux Kernel.

🔻 С признаками эксплуатации вживую опять Remote Code Execution - Chromium (CVE-2024-5274, CVE-2024-4947), как и Microsoft Patch Tuesday. Судя по данным БДУ, Remote Code Execution - Libarchive (CVE-2024-26256) также активно эксплуатируется.

🔸 Ещё 20 уязвимостей с публичным эксплоитом. Можно подсветить отдельно Remote Code Execution - Cacti (CVE-2024-25641) и Remote Code Execution - onnx/onnx framework (CVE-2024-5187).

🗒 Отчёт Vulristics по июньскому Linux Patch Wednesday (4.4 мб.)

upd. 30.06 Обновил отчёт.

Майский Linux Patch Wednesday

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

Майский Linux Patch Wednesday
Майский Linux Patch WednesdayМайский Linux Patch WednesdayМайский Linux Patch WednesdayМайский Linux Patch WednesdayМайский Linux Patch Wednesday

Майский Linux Patch Wednesday. В прошлом месяце мы совместно решили, что стоит ввести правило по Unknown датам с мая 2024. Что я, собственно, и реализовал. Теперь, если я вижу oval definition, для которого нет даты публикации (даты появления исправлений для соответствующих уязвимостей), то я номинально присваиваю сегодняшнюю дату. Таким образом 32406 oval definition-ов без даты получили номинальную дату 2024-05-15. Можно было бы предположить, что мы получим огромный пик для уязвимостей, которые "начали исправляться в мае" исходя из номинальной даты. А как вышло на самом деле?

На самом деле пик получился не очень большой. В майском Linux Patch Wednesday 424 CVE. При том, что в апрельском было 348. Соизмеримо. Видимо не очень большой пик связан с тем, что для большей части уязвимостей уже были даты исправления старше выставленной номинальной (2024-05-15). Тем лучше. 🙂 В июне всё должно стать вообще хорошо.

Как обычно, я сгенерировал отчёт Vulristics для майских уязвимостей. Большая часть уязвимостей (282) относятся к Linux Kernel. Это следствие того, что Linuх Kernel теперь CNA и они могут заводить CVE на всякую дичь типа багов с огромными трейсами прямо в описании уязвимостей.

На первом месте уязвимость из CISA KEV.

🔻Path Traversal - Openfire (CVE-2023-32315). Это трендовая уязвимость августа 2023 года. Она попала в отчёт из-за фикса в RedOS 2024-05-03. А в других Linux дистрибутивах её не фиксили? Похоже, что нет. В Vulners среди связанных объектов безопасности можем видеть только бюллетень RedOS. Видимо в репозиториях других дистрибутивов пакеты Openfire отсутствуют.

На втором месте уязвимость с признаком активной эксплуатации по AttackerKB.

🔻 Path Traversal - aiohttp (CVE-2024-23334). Ошибка позволяет неаутентифицированным злоумышленникам получать доступ к файлам на уязвимых серверах.

По данным из БДУ ещё 16 уязвимостей имеют признаки активной эксплуатации вживую.

🔻 Memory Corruption - nghttp2 (CVE-2024-27983)
🔻 Memory Corruption - Chromium (CVE-2024-3832, CVE-2024-3833, CVE-2024-3834, CVE-2024-4671)
🔻 Memory Corruption - FreeRDP (CVE-2024-32041, CVE-2024-32458, CVE-2024-32459, CVE-2024-32460)
🔻 Memory Corruption - Mozilla Firefox (CVE-2024-3855, CVE-2024-3856)
🔻 Security Feature Bypass - bluetooth_core_specification (CVE-2023-24023)
🔻 Security Feature Bypass - Chromium (CVE-2024-3838)
🔻 Denial of Service - HTTP/2 (CVE-2023-45288)
🔻 Denial of Service - nghttp2 (CVE-2024-28182)
🔻 Incorrect Calculation - FreeRDP (CVE-2024-32040)

Ещё для 22 уязвимостей есть эксплоит (публичный или приватный), но пока нет признаков активной эксплуатации вживую. Все их здесь перечислять не буду, можно обратить внимание на:

🔸 Security Feature Bypass - putty (CVE-2024-31497). Громкая уязвимость, позволяющая атакующему восстановить секретный ключ пользователя.
🔸 Remote Code Execution - GNU C Library (CVE-2014-9984)
🔸 Remote Code Execution - Flatpak (CVE-2024-32462)
🔸 Command Injection - aiohttp (CVE-2024-23829)
🔸 Security Feature Bypass - FreeIPA (CVE-2024-1481)

Думаю, что в качестве улучшения в отчёте Vulristics можно отдельно группировать уязвимости с публичными эксплоитами и приватными эксплоитами, т.к. всё-таки это сильно влияет на критичность. Ставьте 🐳, если нужно такое сделать.

🗒 Отчёт Vulristics по майскому Linux Patch Wednesday

По Linux Patch Wednesday можно задать справедливый вопрос: а правильно ли я отношу уязвимости к месяцам?

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

По Linux Patch Wednesday можно задать справедливый вопрос: а правильно ли я отношу уязвимости к месяцам?

По Linux Patch Wednesday можно задать справедливый вопрос: а правильно ли я отношу уязвимости к месяцам?

Напомню текущую логику: я беру таймстемпы бюллетеней из OVAL-контента Linux вендоров. Какой таймстемп самый старый, тот и считаю временем первого исправления уязвимости.

Но вот незадача: первыми обычно выпускают исправления Debian и они же, частенько, не указывают дату бюллетеня в OVAL (и в листах рассылки тоже не всегда). 😣 Вот и получается как на картинке. Debian выпустил патч непонятно когда, а RedOS в апреле 2024. Делаем вывод, что уязвимость апрельская, ага. Хотя "2023" в CVE намекает на то, что это, мягко говоря, не совсем так и первое исправление уязвимости вышло значительно раньше.

Что с этим делать? Можно сделать радикальный шаг: если для CVE в источнике дата Unknown, то тупо выставлять текущую дату. "Если вижу исправление и не знаю когда конкретно уязвимость была исправлена, значит она была исправлена сегодня". 🙂 И проводить такую "раздачу дат" для Unkown более-менее регулярно (не реже раза в месяц).

К чему приведет введение такого правила со следующего Linux Patch Wednesday? К тому, что огромная масса уязвимостей, которые непонятно когда были исправлены, станут "исправлены" в мае 2024 года. Мы на них посмотрим, ужаснёмся разок, но зато в следующих месяцах всплывающих внезапно старых уязвимостей будет минимальное количество. Там будет в основном свежачок. Но зато я попорчу статистику внезапным пиком в мае 2024. Дилемма. 🤷‍♂️

Как считаете, проводим операцию "Введение правила по Unknown датам с Мая 2024?".

Кит 🐳, если да (ввести правило, получить пик в статистике ради будущих красивых отчётов без старья).

Палец вниз 👎, если нет (оставить как есть в надежде, что в будущем появится хороший источник данных по таймстемпам исправления и статистика автоматом пересчитается правильным образом).

Сам я считаю, что ввести такое правило стоит.