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

Про уязвимость Elevation of Privilege - Linux Kernel "Dirty Frag" (CVE-2026-43284, CVE-2026-43500)

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

Про уязвимость Elevation of Privilege - Linux Kernel Dirty Frag (CVE-2026-43284, CVE-2026-43500)

Про уязвимость Elevation of Privilege - Linux Kernel "Dirty Frag" (CVE-2026-43284, CVE-2026-43500). По информации исследователя Hyunwoo Kim (@v4bel), Dirty Frag - это уязвимость (класс уязвимостей), которая позволяет локальному непривилегированному злоумышленнику получить права root на большинстве Linux-дистрибутивов путем объединения уязвимости xfrm-ESP Page-Cache Write (CVE-2026-43284) и уязвимости RxRPC Page-Cache Write (CVE-2026-43500). Эксплуатация этой цепочки позволяет злоумышленнику полностью скомпрометировать систему: получить доступ к любым файлам, отключить защиту, закрепиться в системе и использовать хост для дальнейших атак.

⚙️🛠 Описание цепочки уязвимостей, технический write-up и эксплойт были опубликованы 7 мая. Эксплуатабельность была подтверждена на актуальных дистрибутивах Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44. Уязвимость xfrm-ESP Page-Cache Write присутствует в ядре начиная с cac2661c53f3 (2017-01-17) и вплоть до актуальной upstream-версии, а уязвимость RxRPC Page-Cache Write присутствует в ядре начиная с 2dc334f1a63a (2023-06) и вплоть до актуальной upstream-версии. Другими словами, фактический срок присутствия этих уязвимостей в ядре составляет около 9 лет.

Информация об уязвимости и эксплойт были опубликованы до появления пакетов, устраняющих уязвимость в дистрибутивах. Как сообщает исследователь, 7 мая он отправил подробную информацию об уязвимости и эксплоите в список рассылки linux-distros. Эмбарго было установлено на 5 дней, с соглашением, что если третья сторона опубликует эксплойт в интернете в течение этого периода, эксплойт "Dirty Frag" будет опубликован в открытом доступе. В тот же день так и произошло, информация утекла в паблик, эмбарго было нарушено. 🤷‍♂️ После чего уже сам исследователь сделал full disclosure.

Аналогичная громкая уязвимость прошлой недели Elevation of Privilege - Linux Kernel "Copy Fail" (CVE-2026-31431) послужила мотивацией для начала исследования "Dirty Frag". Как сообщает исследователь, xfrm-ESP Page-Cache Write в "Dirty Frag" использует тот же sink, что и "Copy Fail". Однако "Dirty Frag" срабатывает независимо от того, доступен ли модуль algif_aead. Иными словами, даже в системах, где применён workaround для "Copy Fail" (blacklist для algif_aead), Linux остаётся уязвимым для "Dirty Frag".

Почему используется цепочка из двух уязвимостей? Как сообщает исследователь, xfrm-ESP Page-Cache Write предоставляет мощный примитив произвольной 4-байтной записи (STORE) ("powerful arbitrary 4-byte STORE primitive"), аналогичный Copy Fail, и присутствует в большинстве дистрибутивов, однако для его использования требуется привилегия на создание namespace. В Ubuntu создание непривилегированных user namespace иногда блокируется политикой AppArmor. В такой среде xfrm-ESP Page-Cache Write не может быть вызван ("triggered"). RxRPC Page-Cache Write не требует привилегии на создание namespace, однако сам модуль rxrpc.ko отсутствует в большинстве дистрибутивов. Тем не менее, в Ubuntu модуль rxrpc.ko загружается по умолчанию. Объединение двух вариантов в цепочку позволяет перекрыть слепые зоны друг друга, что даёт возможность получить root-привилегии на всех основных дистрибутивах.

По состоянию на 8 мая исправление для xfrm-ESP Page-Cache Write (CVE-2026-43284) было замержено в основную ветку ядра, а исправление для RxRPC Page-Cache Write (CVE-2026-43500) ещё нет. Следует отслеживать появление пакетов обновлений CVE-2026-43284, CVE-2026-43500 для используемых Linux-дистрибутивов и своевременно устанавливать их. В качестве workaround-а исследователь уязвимости предлагает скрипт, который запрещает загрузку модулей esp4, esp6 и rxrpc, пытается выгрузить их из ядра и очищает кэш памяти Linux:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

Про уязвимость Elevation of Privilege - Linux Kernel "Copy Fail" (CVE-2026-31431)

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

Про уязвимость Elevation of Privilege - Linux Kernel Copy Fail (CVE-2026-31431)

Про уязвимость Elevation of Privilege - Linux Kernel "Copy Fail" (CVE-2026-31431). Уязвимость локального повышения привилегий в компоненте ядра Linux AF_ALG, которая вызвана ошибкой работы с памятью, позволяет непривилегированному пользователю поднять привилегии до root-а. Проэксплуатировав эту уязвимость, злоумышленник может полностью захватить систему: читать и изменять любые файлы, включая пароли и ключи, подменять системные бинарные файлы, отключать защитные механизмы и средства мониторинга, незаметно устанавливать бэкдоры и закрепляться в системе, скрывать следы своей активности, использовать хост как плацдарм для атак на другие сетевые активы.

⚙️🛠 1 апреля патчи, устраняющие уязвимость, были внесены в основную ветку Linux Kernel. 22 апреля был заведён CVE идентификатор уязвимости. 29 апреля эксперты компании Theori опубликовали разбор уязвимости и публичный эксплойт. Эксплуатабельность уязвимости была подтверждена на актуальных версиях популярных дистрибутивов Linux: Ubuntu, Amazon Linux, RHEL, SUSE.

👾 1 мая уязвимость была добавлена в CISA KEV, что свидетельствует об эксплуатации уязвимости в реальных атаках.

Что отличает эту уязвимость от подобных EOP/LPE в Linux?

В Linux Kernel уже были громкие уязвимости повышения привилегий. Dirty Cow требовала выигрыша в race condition. Часто приходилось делать несколько попыток, и иногда это приводило к падению системы. Dirty Pipe была привязана к конкретным версиям и требовала точных манипуляций с pipe buffer.

Но, в отличие от Dirty Cow и Dirty Pipe, как сообщают исследователи, Copy Fail - это прямолинейная логическая ошибка. Она срабатывает без гонок, повторных попыток или нестабильных временных окон, приводящих к сбоям.

🧬 Портируемость. Один и тот же скрипт эксплуатации работает на всех протестированных дистрибутивах и архитектурах, включая Ubuntu, Amazon Linux, Red Hat Enterprise Linux и SUSE Linux Enterprise. Никаких оффсетов под конкретный дистрибутив. Никакой перекомпиляции. В эксплоите нет проверок версии.

✧ Минимализм. Весь эксплойт - это короткий скрипт на Python, использующий только стандартные модули библиотеки os, socket, zlib. Требуется Python 3.10+ для os.splice. Никаких скомпилированных нагрузок, никакой установки зависимостей.

🥷 Скрытность. Операция записи выполняется, минуя обычный путь записи VFS ("ordinary VFS write path"). Повреждённая страница никогда не помечается ядром как dirty в механизме writeback. Стандартные инструменты контроля целостности файлов, сравнивающие контрольные суммы на диске, не заметят эксплуатацию, потому что файл на диске не изменяется. Повреждается только кэш страниц в памяти.

📦 Межконтейнерное воздействие. Кэш страниц разделяется всеми процессами в системе, в том числе между контейнерами. Copy Fail - это не просто локальное повышение привилегий. Это примитив выхода из контейнера и вектор компрометации узла Kubernetes.

Как устранить уязвимость?

Для устранения уязвимости пользователям необходимо обновиться до версий ядра Linux 6.18.22, 6.19.12 и 7.0. Ядро можно собрать самостоятельно или дождаться, когда обновления пакетов ядра выпустит вендор вашего Linux-дистрибутива. По состоянию на 4 мая вышли обновления для Ubuntu, Debian, RHEL, Fedora, SUSE, CloudLinux, Arch Linux, ROSA Linux.

В качестве workaround-а исследователи предлагают заблокировать создание сокетов AF_ALG:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null

До End of Life CentOS 7 осталось 2 недели

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

До End of Life CentOS 7 осталось 2 недели

До End of Life CentOS 7 осталось 2 недели. Самое время проверить не осталось ли где-то в инфраструктуре хостов с этой операционной системой. Куда мигрировать с CentOS 7 не особо понятно. RedHat превратили CentOS в нестабильный дистрибутив CentOS Stream и начали бороться с традиционными альтернативами в виде Alma и Rocky. Можно, конечно, посмотреть в сторону SberLinux, RedOS и Роса «Кобальт», но, имхо, будущее RPM-based дистрибутивов совместимых с RHEL в России достаточно туманно и стоит целиться скорее в Астру или Альт. Судя по статистике, в мире в основном бегут на Ubuntu.

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

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

Прожектор по ИБ, выпуск №4 (24.09.2023). Записали вчера очередной эпизод, состав тот же:

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

0:35 Как зашёл прошлый эпизод
2:08 Лев и Максим делятся впечатлениями от Kazan Digital Week
7:06 На какие мероприятия по ИБ мы ходим
11:06 Приостановка сертификата ФСТЭК на Dr.Web Enterprise Security Suite
19:04 Cisco покупает Splunk
25:59 Про RCE уязвимость BDU:2023-05857 в модулe landing CMS "1С-Битрикс: Управление сайтом".
30:02 Новые подробности инцидента с FDM и скрипт для детекта
32:21 Занятные моменты детектирования Linux уязвимостей на примере CVE-2022-1012, RPM-based дистрибутивы и импортозамещение
44:02 Прощание от Mr. X

Занятный кейс, который вы можете показать своему VM-вендору, конкретно специалистам по детекту уязвимостей Linux

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

Занятный кейс, который вы можете показать своему VM-вендору, конкретно специалистам по детекту уязвимостей Linux

Занятный кейс, который вы можете показать своему VM-вендору, конкретно специалистам по детекту уязвимостей Linux. Есть уязвимость ядра Linux CVE-2022-1012. Вопрос: вы можете продетектировать эту уязвимость в CentOS/RedHat 7?

Уловка в том, что VM-вендоры, как правило, детектируют уязвимости на основе бюллетеней безопасности Linux-вендоров. Т.е. они могут продетектировать только те уязвимости, для которых уже есть фиксы и понимание какие версии пакетов уязвимы. А для этой уязвимости RedHat пишут, что да, она аффектит дистриб, но они не будут исправлять её в CentOS/RedHat 7. Можно было бы предположить, что 7ая версия, наверное, уже EOL. Но нет, для 7ой версии EOL наступит только в июле 2024 года.

Имеем уязвимость, которая

1. Присутствует в ещё поддерживаемой версии ОС.
2. Не может быть исправлена установкой обновления от Linux-вендора.
3. Не может быть продетектирована, если только VM-вендор специально не озаботился детектом "Will not fix" уязвимостей.

Наблюдаю за попыткой Red Hat расправиться с бесплатными клонами RHEL

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

Наблюдаю за попыткой Red Hat расправиться с бесплатными клонами RHEL

Наблюдаю за попыткой Red Hat расправиться с бесплатными клонами RHEL. Они прекратили публиковать srpm-пакеты RHEL в репозитории git.centos.org. Теперь можно будет забирать только исходники пакетов нестабильного дистриба CentOS Stream. 😏 Естественно, Alma и Rocky оказались в щекотливом положении. Вендоров отечественных RPM-based дистрибутивов новость тоже, наверняка, не порадовала. Самый смачный пост был у Mike McGrath, "Vice President of Core Platforms Engineering at Red Hat". Вообще в выражениях не стесняется:

"Я чувствую, что большая часть гнева из-за нашего недавнего решения относительно даунстримов исходит либо от тех, кто не хочет платить за время, усилия и ресурсы, вложенные в RHEL, либо от тех, кто хочет переупаковать их для собственной выгоды. Этот спрос на код RHEL лицемерен."

"В конечном счете, мы не находим ценности в ребилдерах RHEL-а и не обязаны облегчать жизнь ребилдерам"

"Простой ребилд кода без добавления ценности или какого-либо изменения представляет собой реальную угрозу для компаний с открытым исходным кодом во всем мире. Это реальная угроза открытому исходному коду, и она потенциально может вернуть опенсурс обратно в деятельность только для любителей […]".

Вот тебе и опенсурс. Как в КВНе было: "- Дайте полотенце - Вон там, на швабре возьмите". А кто-то ещё критикует МЦСТ за нарушение GPL. 😏

Так-то ещё с закапывания CentOS было понятно, что дело пахнет керосином и бежать нужно не на RHEL-клоны, а куда подальше.

Год с великого исхода западных вендоров: судьба специалиста

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

Год с великого исхода западных вендоров: судьба специалиста. С трудом уже верится, но раньше в РФ было возможно строить IT/ИБ системы, используя западные решения. 🙂 Более того, это был абсолютный мейнстрим. Как следствие, сотрудники российских компаний естественным образом развивались в крутых специалистов по продуктам Microsoft, Oracle, CISCO, PaloAlto, AWS, Tenable/Qualys/Rapid7 и т.д. 😉 Собирали комплекты вендорских сертификатов, выстраивали красивые CV-шки.

Безусловно, в этом была своя прелесть. Ты используешь те же решения, что и крупные компании во всем развитом мире, твои скилы также востребованы в общемировом масштабе. А значит релокация туда, где лучше, выглядит как вполне себе план Б (а у кого-то и как план А). Минусом шла привязка к западным вендорам и их судьбе в России. Но что с ними сделается-то? 😏

Однако оказалось, что сделаться может много чего и очень быстро. И перед российскими специалистами по решениям западных вендоров всерьез встал выбор:

- продолжать делать то, что делали, а значит релоцироваться туда, где можно продолжать строить системы на западных решениях;
- остаться и строить системы на тех решениях, которые остались/появились в РФ;
- остаться, перестать строить системы и принять участие в копировании западных решений.

Релокация это всегда мероприятие на любителя. Тем более сейчас, когда "жить на 2 страны" стало совсем не так просто и комфортно. Переезд на запад теперь выглядит скорее как дорога в один конец.

Остаться и развиваться в чем-то другом это и потеря конкурентных преимуществ, и необходимость быстро учиться новому, и переход в новый локальный контекст. Опыт с Яндекс Клауд и Астра Линукс безусловно менее универсален, чем с AWS и RHEL. 🙂 Это нужно осознать и принять.

Никого не осуждаю, у всех свои ситуации. Но милей мне, безусловно, оставшиеся. Мы в одной лодке, выгребем. 🛶 🙂