Все новости за Май 2026
Опубликован PoC для DirtyDecrypt - новой LPE-уязвимости в ядре Linux
Добавил:
Федор Сорекс, 19.05.2026
Опубликован proof-of-concept для уязвимости DirtyDecrypt, также известной как DirtyCBC, позволяющей локальному непривилегированному пользователю получить права root на некоторых системах Linux. Проблема находится в коде rxgk подсистемы RxRPC и связана с записью в page cache из-за отсутствующей проверки copy-on-write в функции rxgk_decrypt_skb(). О публикации PoC 18 мая 2026 года сообщило издание BleepingComputer; сам PoC размещён в репозитории команды V12.
RxRPC - это сетевой протокол ядра Linux поверх UDP, предоставляющий надёжный транспорт для удалённых операций. В документации ядра отдельно указано, что AFS - Andrew File System - является примером приложения, использующего RxRPC, а сам протокол поддерживает переговоры о безопасности соединения. Именно к этой области относится RxGK, используемый для защищённого режима RxRPC/AFS.
По описанию V12, DirtyDecrypt является ещё одним вариантом уязвимостей класса CopyFail / Dirty Frag / Fragnesia. Все они вращаются вокруг похожей идеи: некорректная работа с памятью ядра, page cache и буферами может позволить непривилегированному локальному процессу повлиять на данные, которые должны быть недоступны для записи. В случае DirtyDecrypt речь идёт о "rxgk pagecache write" из-за отсутствующей COW-защиты в rxgk_decrypt_skb().
Команда V12 утверждает, что обнаружила и сообщила о проблеме 9 мая 2026 года, но сопровождающие ядра ответили, что это дубликат уже исправленной ошибки. После этого исследователи опубликовали PoC, мотивируя это тем, что исправление уже находится в mainline-ядре.
С CVE ситуация выглядит не вполне прямолинейно. BleepingComputer пишет, что отдельного официального CVE именно для имени DirtyDecrypt на момент публикации нет, но аналитик Will Dormann связывает опубликованные V12 детали с CVE-2026-31635, исправленной в конце апреля. В базе NVD CVE-2026-31635 описана как ошибка в rxrpc: функция rxgk_verify_response() некорректно проверяла длину RESPONSE-аутентификатора, из-за чего слишком большой аутентификатор мог попасть в rxgk_decrypt_skb() и довести код до BUG_ON(len).
То есть общедоступные публикации связывают DirtyDecrypt с CVE-2026-31635, но формальное описание CVE в NVD пока выглядит более узким и говорит прежде всего об ошибке проверки длины в rxrpc, а не прямо об alias DirtyDecrypt/DirtyCBC как об отдельной записи. Поэтому корректнее писать: DirtyDecrypt, вероятно, соответствует или тесно связан с CVE-2026-31635, а не утверждать, что это официальное имя CVE.
Для эксплуатации требуется ядро с включённой опцией CONFIG_RXGK, которая включает поддержку RxGK для AFS-клиента и сетевого транспорта. Это заметно сужает круг затронутых систем: в первую очередь речь идёт о дистрибутивах, быстро следующих за upstream-ядром, включая Fedora, Arch Linux и openSUSE Tumbleweed. При этом BleepingComputer подчёркивает, что опубликованный V12 PoC проверялся только на Fedora и mainline-ядре.
DirtyDecrypt появился на фоне целой серии близких по классу Linux LPE-уязвимостей. Ранее были раскрыты Copy Fail в algif_aead, Dirty Frag в сетевых компонентах, а затем Fragnesia в XFRM ESP-in-TCP. Microsoft описывала Dirty Frag как локальное повышение привилегий через компоненты esp4, esp6 и rxrpc, позволяющее атакующему после получения локального доступа подняться до root и закрепиться в системе.
Практическая опасность таких ошибок в том, что они часто используются уже после первичного взлома: например, после компрометации SSH-учётки, web shell, уязвимого контейнера или низкопривилегированного сервисного пользователя. Получив root, атакующий может отключать средства защиты, читать секреты, менять журналы, разворачивать persistence и двигаться дальше по инфраструктуре.
Пользователям потенциально затронутых rolling-release-дистрибутивов рекомендуется установить последние обновления ядра. Для систем, где немедленное обновление невозможно, в публикациях упоминаются временные меры вроде отключения неиспользуемых rxrpc-модулей и связанных компонентов, однако такие обходные решения могут сломать AFS и часть IPsec/VPN-сценариев, поэтому применять их нужно только после проверки влияния на конкретную систему.
Для большинства настольных и серверных установок риск, вероятно, ниже, чем у Copy Fail: DirtyDecrypt требует наличия конкретной конфигурации ядра и локального выполнения кода. Тем не менее для Fedora, Arch Linux, openSUSE Tumbleweed и других систем с быстрым обновлением ядра проблема заслуживает внимания: это уже не теоретический отчёт, а уязвимость с опубликованным PoC и понятным путём к повышению привилегий.
[Подробности]
[Источник]
Релиз OpenBSD 7.9
Добавил:
Федор Сорекс, 19.05.2026
вышел юбилейный 60-ый выпуск операционной системы OpenBSD.
Среди изменений:
- улучшение поддержки архитектур arm64, luna88k, riscv64, и других;
- исправление уязвимости FP-DSS на amd64;
- механизм sysctl hw.smt объявлен устаревшим, вместо него - hw.blockcpu, чтобы исключить определенные виды ядер из планировщика (полезно для процессоров Intel);
- реализован механизм delayed hibernation, известный в systemd как suspend-then-hibernate;
- улучшения в SMP;
- компонент DRM из ядра Linux обновлён до версии 6.18.22;
- исправлены многие баги в подсистеме виртуализации VMM/VMD;
- множество улучшений в программах пространства пользователя, например, login способен выставлять переменную окружения XDG_RUNTIME_DIR, необходимую для композиторов Wayland;
- улучшена поддержка сетевых устройств, в частности:
- добавлена поддержка ширины канала 160 МГц в диапазоне 5 ГГц в драйвере iwx;
- добавлена базовая поддержка 802.11ax (WiFi 6);
- улучшения подсистем pledge и unveil;
- IPv6 autoconf (DHCP) включен по умолчанию в установщике;
- LibreSSL версии 4.3.0;
- OpenSSH версии 10.3;
- и многое другое, с чем можно ознакомиться самостоятельно.
Для платформы amd64 подготовлено 13044 бинарных пакетов, среди которых Chromium 147, Firefox 150, GCC 15.2.0, LLVM/Clang 19.1.7 и 20.1.8, GNOME 49, KDE Plasma 6.6.4, Wayland-композиторы Niri, Mango, LabWC, Sway, Wayfire.
Впервые после перерыва была выпущена официальная песня, однако русскоязычным сообществом подготовлена и неофициальная песня.
[Подробности]
[Скачать]
Модель угроз и особенности оценки уязвимостей в ядре Linux
Добавил:
Федор Сорекс, 19.05.2026
Линус Торвальдс принял в состав ядра документ, регламентирующий процесс обработки ошибок, связанных с безопасностью, определяющий модель угроз, поясняющий, какие ошибки в ядре трактуются как уязвимости, и разбирающий действия с ошибками, выявленными при помощи AI. Документ подготовлен Вилли Тарро (Willy Tarreau), автором HAProxy и давним разработчиком ядра Linux, отвечавшим за сопровождение нескольких стабильных веток ядра. В качестве основы использованы договорённости, достигнутые в ходе обсуждения недавно выявленных критических уязвимостей в ядре ("Copy Fail", "Dirty Frag", "Fragnesia", "ssh-keysign-pwn"), раскрытых до публикации исправлений и для которых, благодаря AI, удалось сразу создать рабочие эксплоиты.
Основную массу связанных с безопасностью ошибок предписывается обрабатывать публично, чтобы привлечь максимально широкую аудиторию и найти оптимальное решение. В отдельный приватный список рассылки предлагается отправлять только экстренные сообщения об уязвимостях, легко эксплуатируемых, представляющих угрозу для многих пользователей и позволяющих получить расширенные привилегии или возможности.
Уязвимости, выявленные при помощи AI-ассистентов, всегда предлагается обсуждать публично, так как подобные проблемы часто обнаруживаются одновременно несколькими исследователями. При этом не следует раскрывать в отчёте эксплоит ? достаточно упомянуть, что он доступен, и передать его в частном порядке в ответ на запрос сопровождающего.
Отдельно описываются правила передачи отчётов, созданных при помощи AI-ассистентов. Подобных отчётов присылают очень много и благодаря им время от времени удаётся выявлять ошибки в плохо отрецензированных частях кода, но сопровождающие часто их игнорируют из-за низкого качества и неточностей.
Основные требования к отчётам, созданными при участии AI:
- Краткость, без воды и с указанием сути и важных деталей в самом начале.
- Только голый текст без Markdown-тегов и декорирования.
- Понимание модели угроз и указание проверяемых фактов (например, "ошибка позволяет любому пользователю получить CAP_NET_ADMIN"), а не теоретических измышлений и домыслов о последствиях уязвимости.
- Перед отправкой отчёта обязательно тщательно протестировать работоспособность эксплоита, сформированного через AI, и убедиться в возможности воспроизвести проблему.
- Привлечение AI для разработки и тестирования исправления выявленной проблемы.
По статистике сопровождающих, большинство отчётов об ошибках, присылаемых под видом устранения уязвимостей, таковыми не являются, и должны обрабатываться в общем порядке как обычные ошибки. Для разделения уязвимостей и обычных ошибок описана модель угроз ядра Linux. Среди возможностей и гарантий, нарушение которых может рассматриваться как уязвимость:
- Изоляция на уровне пользователей: доступ к файлам только для владельца, память процесса недоступна другим пользователям, ptrace запрещён для чужих процессов, изоляция IPC и сетевых коммуникаций.
- Защита на основе capabilities: без CAP_SYS_ADMIN нельзя менять конфигурацию ядра, память, состояние системы, без CAP_NET_ADMIN нельзя менять сетевые настройки или перехватывать трафик, без CAP_SYS_PTRACE нельзя отслеживать процессы других пользователей.
- Пространство имён идентификаторов пользователей (CONFIG_USER_NS) позволяет непривилегированным пользователям создавать свои изолированные окружения, из которых нельзя влиять на глобальное пространство имён, например, менять время, загружать модули и монтировать блочные устройства.
- Отладочные интерфейсы (/proc/kmsg, perf, debugfs), через которые можно получить доступ к конфиденциальной информации, доступны только после явного предоставления доступа администратором.
Возможности, которые не рассматриваются как уязвимости:
- Использование устаревших веток ядра.
- Сборка с включением опций для разработчиков или снижающих безопасность (например, CONFIG_NOMMU).
- Выставление небезопасных настроек sysctl, опций командной строки, прав доступа в ФС, capabilities или открытие непривилегированным пользователям доступа к привилегированным интерфейсам (например, доступ на запись в procfs и debugfs).
- Проблемы в функциях, предназначенных только для разработки и отладки ядра, таких как LOCKDEP, KASAN и FAULT_INJECTION, которые не предназначены для включения в рабочих конфигурациях.
- Проблемы в драйверах, модулях и подсистемах, находящихся в секции STAGING или помеченных как экспериментальные, небезопасные или неработоспособные.
- Использование сторонних модулей ядра или неофициальных форков ядра.
- Требование избыточных привилегий, таких как необходимость выполнения действий с правами root или от пользователя, имеющего права CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO и CAP_SYS_MODULE.
- Теоретические атаки, требующие лабораторных условий, миллиардов попыток, эмуляции или модификации оборудования, несоразмерных затрат и нереалистичных конфигураций (например, системы с десятками тысяч ядер CPU).
- Обход механизмов защиты (например, ASLR) без демонстрации эксплоита. Отсутствие проверок аргументов и возвращаемых кодов ошибок, не имеющих явных последствий.
- Случайные утечки информации, неподконтрольные атакующим, такие как
остаточные данные в сообщениях об ошибках и утечки адресов/указателей на память ядра без прямой возможности эксплуатации.
- Ошибки при монтировании повреждённых дисковых образов, если драйвер не заявлен как пригодный для использования с не заслуживающими доверия носителями. Проблемы с дисковыми образами, выявляемые и устраняемые через запуск утилиты fsck.
- Атаки требующие физического доступа к оборудованию, модификации оборудования или подключения аппаратных устройств, таких как платы для атаки на DMA и логические анализаторы, если система специально не настроена для защиты от подобных атак (IOMMU).
- Регрессии c функциональностью и производительностью, устраняемые настройкой прав и лимитов.
[Подробности]