🐧 Linux: CVE-2026-31431 «Copy Fail» — LPE до root из 732 байт Python-кода

Коллеги, 30 апреля опубликованы подробности уязвимости, которая затрагивает практически каждый Linux-сервер в вашей инфраструктуре. Срочно читать.

CVE-2026-31431 «Copy Fail» — локальное повышение привилегий до root для любого локального пользователя без специальных условий. Уязвимость присутствует в ядрах начиная с Linux 4.14 (2017 год). Эксплоит — 732 байта Python-кода, уже опубликован.

Проблема в authencesn — криптографическом шаблоне ядра — и эксплуатируется через интерфейс AF_ALG. Исправлена в ядрах 6.18.22, 6.19.12 и 7.0.

Действия прямо сейчас:

# ШАГ 1 — Проверяем версию ядра
uname -r
# Затронуты: 4.14 — 6.19.11, 6.18.0 — 6.18.21

# ШАГ 2 — Митигейшн БЕЗ перезагрузки (если патч ещё не вышел)
# Отключаем модуль algif_aead
lsmod | grep algif_aead
rmmod algif_aead 2>/dev/null || echo "Module not loaded — safe"

# Запрещаем загрузку модуля навсегда:
echo "install algif_aead /bin/false" >> /etc/modprobe.d/disable-algif-aead.conf
echo "blacklist algif_aead" >> /etc/modprobe.d/disable-algif-aead.conf

# ШАГ 3 — Обновляем ядро (для дистрибутивов с патчем)
# Ubuntu 22.04 / 24.04:
apt update && apt install --only-upgrade linux-image-generic -y

# RHEL 9 / AlmaLinux 9 / Rocky 9:
dnf update kernel -y

# Debian 12:
apt update && apt full-upgrade -y

# ШАГ 4 — Проверяем активность AF_ALG в среде
# Смотрим открытые AF_ALG сокеты
ss -a | grep ALG
# Если пусто — модуль не используется, отключение безопасно

# ШАГ 5 — Перезагружаемся после обновления ядра
# Проверяем что загрузились с новым ядром:
uname -r  # должен показать исправленную версию

Зачем это важно:
Уязвимость быстро закроют в облаках и Kubernetes-кластерах. Но длинный хвост старых и забытых Linux-систем — роутеры, IoT, терминалы, промышленные системы — останется уязвимым ещё годами. В вашей инфраструктуре наверняка есть такие «забытые» хосты.

Итог: два действия сегодня — blacklist algif_aead на всех серверах где нет патча, обновить ядро там где патч доступен. PoC публичный, счёт идёт на часы.

#linux #cve #kernel #security #lpe #sysadmin #admin_future

🪟 Windows: PhantomRPC — архитектурная дыра в RPC без патча и без CVE

Коллеги, 24 апреля на Black Hat Asia 2026 Kaspersky раскрыли уязвимость, которую Microsoft отказалась патчить. Называется PhantomRPC — и она касается каждой Windows-машины в вашей инфраструктуре.

PhantomRPC эксплуатирует архитектурную слабость в том, как Windows RPC runtime (rpcrt4.dll) обрабатывает подключения к недоступным RPC-серверам. Когда привилегированный процесс пытается подключиться к отключённому сервису, система не проверяет легитимность ответившего сервера. Атакующий с доступом уровня NT AUTHORITY\NETWORK SERVICE разворачивает вредоносный RPC-сервер, перехватывает вызов и через RpcImpersonateClient получает токен SYSTEM.

Microsoft оценила проблему как moderate severity и закрыла тикет без CVE и без запланированного патча, сославшись на то что для атаки нужен SeImpersonatePrivilege. Kaspersky с этим не согласны — этот привилей есть у огромного числа сервисных аккаунтов по умолчанию.

Что делать сегодня — три митигейшна:

# ШАГ 1: ETW-мониторинг RPC-активности
# Ловим RPC_S_SERVER_UNAVAILABLE (Event ID 1) от привилегированных процессов

# Включаем расширенный аудит RPC:
auditpol /set /subcategory:"RPC Events" /success:enable /failure:enable

# Ищем подозрительную активность в логах:
Get-WinEvent -LogName "Microsoft-Windows-RPC/Admin" -MaxEvents 100 |
    Where-Object {$_.Id -eq 1} |
    Select-Object TimeCreated, Message |
    Format-List

# ШАГ 2: Ограничиваем SeImpersonatePrivilege
# Смотрим кто имеет этот привилей (должны быть только системные аккаунты):
$accounts = @()
$policy = secedit /export /cfg "$env:TEMP\secpol.cfg" /quiet
Get-Content "$env:TEMP\secpol.cfg" |
    Select-String "SeImpersonatePrivilege" |
    ForEach-Object { Write-Host $_ }
# Убираем лишние аккаунты через GPO:
# Computer Config -> Security Settings -> User Rights Assignment
# -> Impersonate a client after authentication

# ШАГ 3: Держим критичные сервисы запущенными
# Если TermService, DHCP Client, W32Time запущены —
# атакующий не может занять их endpoint
Get-Service TermService, Dhcp, W32Time | Select-Object Name, Status

# Убеждаемся что они в автозапуске:
Set-Service TermService -StartupType Automatic
Set-Service Dhcp -StartupType Automatic
Set-Service W32Time -StartupType Automatic
Start-Service TermService, Dhcp, W32Time

# ШАГ 4: Инструменты Kaspersky для аудита (GitHub: PhantomRPC repo)
# Позволяют найти exploitable RPC call patterns в своей среде

Зачем это важно:
Это не единственный баг в одном компоненте. Kaspersky указывают на системную слабость в том, как Windows обрабатывает провенанс RPC-серверов — значит, новые векторы атаки через эту архитектуру будут появляться и дальше.

Итог: патча нет и не предвидится. Мониторинг ETW, минимизация SeImpersonatePrivilege и запущенные сервисы-«заглушки» — это всё что есть прямо сейчас. Мало, но лучше чем ничего.

#windows #security #rpc #phantomrpc #lpe #sysadmin #admin_future

🐧 Linux: Dirty Frag — вчера вечером раскрыли новый LPE, патчей ещё нет

Коллеги, срочная новость прямо с вчерашнего вечера. 8 мая независимый исследователь Хёнву Ким опубликовал Dirty Frag — два новых CVE в ядре Linux с публичным PoC и без патчей. Это не учебная тревога.

CVE-2026-43284 и CVE-2026-43500 — пара связанных уязвимостей в IPsec ESP и RxRPC подсистемах ядра. Любой непривилегированный локальный пользователь получает root. В отличие от Copy Fail с 4-байтовой записью, Dirty Frag позволяет полностью контролируемую запись в page cache в произвольном месте — за один выстрел. Исследователь сообщает о очень высокой надёжности без риска kernel panic.

Что делает это особенно опасным: контейнерные workloads наследуют уязвимость хоста — компрометация любого контейнера с доступом к AF_KEY, XFRM netlink или AF_RXRPC сокетам (дефолт для Docker, containerd и большинства Kubernetes pods) даёт root на хосте.

Embargo было нарушено третьей стороной, что вынудило исследователя опубликовать раньше срока — до выхода патчей дистрибутивов.

# МИТИГЕЙШН — НЕМЕДЛЕННО, пока патчей нет:
# Блокируем три затронутых модуля

sudo sh -c "printf 'install esp4 /bin/false\n\
install esp6 /bin/false\ninstall rxrpc /bin/false\n' \
> /etc/modprobe.d/dirtyfrag.conf"

# Выгружаем если уже загружены:
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true

# Проверяем что модули не загружены:
lsmod | grep -E "esp4|esp6|rxrpc"
# Пустой вывод = в безопасности

# Проверяем затронуты ли конкретные версии ядра:
uname -r
# Затронуты ВСЕ дистрибутивы с ядром 2017+ до появления патча

# Следим за патчами:
# AlmaLinux: almalinux.org/blog
# Ubuntu: ubuntu.com/security/notices
# RHEL: access.redhat.com/security/vulnerabilities

# Мониторим загрузку подозрительных модулей:
auditctl -a always,exit -F arch=b64 \
    -S finit_module -S init_module \
    -k kernel_module_load

Зачем это критично сегодня:
Dirty Frag — прямой наследник Copy Fail того же класса уязвимостей. PoC публичен, патчей пока нет ни у одного дистрибутива. Организации должны считать уязвимость валидной и эксплуатируемой прямо сейчас.

Итог: три команды — один blacklist-файл — перезагрузка. Делай это сейчас, пока читаешь пост. Патч поставишь когда выйдет.

#linux #kernel #cve #dirtyfrag #security #lpe #sysadmin #admin_future

-🐧 Linux: Fragnesia — третья уязвимость за две недели, и у неё нет CVE

Коллеги, вчера 13 мая вышел ещё один сюрприз. Команда v12-security раскрыла «Fragnesia» — универсальный LPE-эксплойт в ядре Linux, обнаруженный Уильямом Боулингом. Fragnesia относится к семейству Dirty Frag, но это отдельная ошибка в ESP/XFRM — она получила собственный патч. Митигейшн — тот же что и для Dirty Frag.

Механика: эксплойт использует логическую ошибку в подсистеме XFRM ESP-in-TCP. Когда TCP-сокет переходит в режим espintcp ULP после того как данные уже были перемещены через splice из файла, достигается произвольная байтовая запись в page cache read-only файлов — без race condition.

Это уже третья уязвимость класса page-cache write за две недели: Copy Fail → Dirty Frag → Fragnesia.

Критическое предупреждение после эксплуатации: после запуска эксплойта /usr/bin/su в page cache остаётся изменённым и будет порождать root-шелл при каждом вызове — до принудительного сброса кэша или перезагрузки.

# МИТИГЕЙШН — тот же что для Dirty Frag
# Блокируем esp4, esp6, rxrpc:
printf 'install esp4 /bin/false\n\
install esp6 /bin/false\n\
install rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf
rmmod esp4 esp6 rxrpc 2>/dev/null || true

# Если система уже была под атакой — ОБЯЗАТЕЛЬНО сбрасываем page cache:
echo 1 | tee /proc/sys/vm/drop_caches
# Или перезагружаемся

# Проверяем что модули не загружены:
lsmod | grep -E "esp4|esp6|rxrpc"
# Пустой вывод = хорошо

# Для систем использующих IPsec — только патч ядра:
# Нужна версия с патчем Fragnesia (появится в 7.0.7+ / 6.18.30+)
# Следим: kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.0.7

# AMD CPU op-cache: отдельная уязвимость этой недели (не ядро Linux)
# Затрагивает Zen 2. Патч от AMD — через обновление microcode:
apt update && apt install amd64-microcode  # Debian/Ubuntu
dnf update microcode_ctl               # RHEL/Rocky/AlmaLinux

Зачем это важно именно сейчас:
Три LPE за две недели из одной поверхности атаки (page cache / XFRM / ESP) говорят об одном: этот класс уязвимостей ещё не исчерпан. Killswitch-proposal от Левина выглядит уже не паранойей, а инженерным реализмом.

Итог: митигейшн простой — blacklist трёх модулей. Если IPsec не используется — делать прямо сейчас. Если используется — в приоритет патч ядра как только появится.

#linux #kernel #cve #fragnesia #lpe #security #sysadmin #admin_future

🐧 Linux: Bad Epoll — новый LPE из 2026-го, патч вышел 2 июля. Обновляемся.

Коллеги, добрый понедельник и добро пожаловать во второе полугодие. Начинаем не с отдыха — с нового LPE.

CVE-2026-46242 «Bad Epoll» — очередной локальный побег в root, опубликованный на прошлой неделе. Уязвимость затрагивает Linux-десктопы, серверы и Android-устройства, патч доступен. Параллельно Greg Kroah-Hartman анонсировал стабильные ядра 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 и 5.10.260, включающие фикс для уязвимости в IPv6 (CVE-2026-53362), позволявшей атакующему выбраться из контейнера и получить root, и use-after-free в KVM (CVE-2026-53359), появившегося ещё в ядре 2.6.36.

Это уже восьмой по счёту публичный LPE в ядре Linux с начала года.

# Проверяем версию ядра — нужны 7.1.3 / 6.18.38 / 6.12.95+:
uname -r

# Обновляем немедленно:
apt update && apt full-upgrade -y && reboot   # Ubuntu/Debian
dnf update kernel -y && reboot               # RHEL/Rocky/AlmaLinux

# Дополнительно: CVE-2026-53362 — IPv6 container escape
# Если используете cgroups v1 (более старые среды):
cat /sys/fs/cgroup/cgroup.controllers 2>/dev/null
# Пусто = cgroups v2 (безопаснее), если есть вывод — v1 активен

# Проверяем есть ли cgroups v1 в контейнерных средах:
cat /proc/1/cgroup | head -5

# CISA также добавила CVE-2022-0492 в KEV:
# cgroup_release_agent_write() — container escape через cgroups v1
# Затрагивает ядра 2.6 - 4.20 и 5.5 - 5.17
# Если у тебя в контейнерах cgroups v1 — это активный вектор

# Принудительный переход на cgroups v2 (ломает часть legacy):
# В /etc/default/grub добавить в GRUB_CMDLINE_LINUX:
# systemd.unified_cgroup_hierarchy=1
# update-grub && reboot

# Неделя 27 — также критичные обновления для glibc и nginx:
apt-get install --only-upgrade nginx glibc-source libglib2.0-0 2>/dev/null
dnf update glibc nginx -y 2>/dev/null

Администраторам следует приоритизировать применение обновлений ядра и glibc немедленно, так как эти компоненты лежат в основе большинства затронутых сервисов на всех дистрибутивах.

Итог: восемь LPE за полгода — это новая реальность. Автоматизированный patch pipeline это уже не nice-to-have, это гигиена. Обновляем ядро и glibc сегодня.

#linux #kernel #cve #badepoll #lpe #security #sysadmin #admin_future

🐧 Linux: DirtyClone — невидимый LPE который не оставляет следов в логах

Коллеги, добрый вторник. Пока Bad Epoll ещё патчируется на флотах, JFrog Security Research опубликовали разбор DirtyClone (CVE-2026-43503) — и это один из самых технически изощрённых LPE в серии. CVSS 8.8.

Что делает DirtyClone особенным: атака генерирует ноль записей в kernel audit log. Ваш AIDE и Tripwire не заметят ничего — бинарь на диске не изменится. Изменится только его копия в page cache памяти. Это делает DirtyClone особенно опасным в multi-tenant средах и Kubernetes-кластерах.

Механика: баг в функции __pskb_copy_fclone() — она сбрасывает флаг SKBFL_SHARED_FRAG при клонировании сетевых пакетов. Этот флаг — маркер безопасности: "эта память файловая, не пиши в неё напрямую". Без флага ядро разрешает in-place запись. Атакующий загружает /usr/bin/su в page cache, заворачивает эти страницы в сетевой пакет, клонирует через TEE-правило netfilter, прогоняет через IPsec-туннель — и IPsec-дешифрование перезаписывает бинарь в памяти. Следующий вызов su — это уже код атакующего с root-привилегиями.

Наибольший риск несут multi-tenant облака, Kubernetes-кластеры и контейнерные workload-ы с включёнными user namespaces — любое ядро без полного patch chain CVE-2026-43503 остаётся уязвимым, даже если оригинальные DirtyFrag патчи были применены.

# ВАЖНО: это НЕ один патч — это серия из четырёх CVE
# Нужна именно полная серия для DirtyFrag + DirtyClone

# Проверяем версию ядра (нужна 7.1.3+ / 6.18.38+ / 6.12.95+):
uname -r

# Обновляем:
apt update && apt full-upgrade -y && reboot   # Debian/Ubuntu
dnf update kernel -y && reboot               # RHEL/Rocky/AlmaLinux

# МИТИГЕЙШН без перезагрузки:
# Ограничиваем user namespaces:
sysctl -w kernel.unprivileged_userns_clone=0  # Debian/Ubuntu
sysctl -w user.max_user_namespaces=0          # RHEL/Fedora

# Blacklist модулей IPsec (если не используется):
printf "install esp4 /bin/false\n\
install esp6 /bin/false\n\
install rxrpc /bin/false\n" | \
    tee /etc/modprobe.d/dirtyclone.conf
rmmod rxrpc esp4 esp6 2>/dev/null || true

# После патча — сбрасываем page cache:
echo 3 | tee /proc/sys/vm/drop_caches

# Проверяем что все четыре CVE серии закрыты:
zcat /proc/config.gz 2>/dev/null | grep CONFIG_XFRM || \
    cat /boot/config-$(uname -r) | grep CONFIG_XFRM

Итог: DirtyFrag-класс, вероятно, ещё не исчерпан — любая функция, которая перемещает fragment descriptors без сохранения shared-frag бита, является потенциальным новым CVE. Патч + перезагрузка — единственное закрытие. Остальное — стопгэп.

#linux #kernel #dirtyclone #lpe #security #контейнеры #sysadmin #admin_future

🐧 Linux: GhostLock — 15-летний баг с 97% надёжностью и цепочкой до браузера

Коллеги, добрая среда. Пока всё внимание было на июльский Patch Tuesday, на прошлой неделе Nebula Security раскрыли GhostLock (CVE-2026-43499) — и это один из самых серьёзных LPE 2026 года.

Use-after-free в подсистеме real-time mutex ядра Linux, существующий с 2011 года. Nebula добились 97% надёжности эксплойта через Google kernelCTF и получили $92,337 в рамках bug bounty. Эксплойт не только даёт root — он также позволяет выбраться из контейнера.

Но самое интересное — GhostLock является второй половиной цепочки IonStack: первая половина (CVE-2026-10702) — это уязвимость Firefox, которая выполняет код внутри браузера и выбирается из его sandbox. GhostLock несёт его дальше — до root. Одна вредоносная ссылка → root на системе.

Неприятный нюанс с патчами: оригинальный фикс привнёс отдельный краш-баг (CVE-2026-53166), и cleanup для него ещё стабилизировался в начале июля — ранние сборки могут не содержать финальную версию.

# Проверяем версию ядра — нужна актуальная с ПОЛНЫМ фиксом:
uname -r

# Ubuntu: проверяем конкретный advisory для своей версии LTS
# (Ubuntu 24.04, 22.04, 20.04 всё ещё могут быть listed as vulnerable)
ubuntu-security-status --verbose | grep -i ghostlock
# или:
apt-cache policy linux-image-$(uname -r) | grep Candidate

# Обновляем + проверяем что взяли именно финальный фикс:
apt update && apt full-upgrade -y
uname -r  # после reboot проверяем новую версию

# RHEL/Rocky/AlmaLinux:
dnf update kernel -y && reboot

# Проверяем два build flags которые усложняют эксплуатацию
# (не фикс, но mitigation):
cat /boot/config-$(uname -r) | grep -E "RANDOMIZE_KSTACK|STATIC_USERMODE"

# Приоритизация: патчить первыми shared/multi-tenant машины,
# cloud серверы, контейнерные хосты и CI-runners

Открытие GhostLock было сделано с помощью AI-инструмента VEGA от Nebula Security — автоматизированного баг-хантера. Futex priority inheritance датируется 2011 годом: старый, активно используемый код ядра, который почти никто не перечитывал годами — пока автоматизированные инструменты не начали его сканировать.

Итог: не все LPE одинаковы. GhostLock + IonStack — это браузер → root одним кликом. Это высшая лига. Проверь что взял финальный патч, а не первый фикс с краш-багом.

#linux #kernel #ghostlock #lpe #security #sysadmin #admin_future

🧠 Skills: Veeam Agent CVE-2026-32996 — эксплуатируется или нет? Разбираем, где факт, а где заголовок.

Коллеги, на этой неделе новость «Veeam эксплуатируется в дикой природе» разошлась по лентам. Хороший повод проверить, на чём она держится.

ФАКТЫ:
CVE-2026-32996, Veeam Agent for Microsoft Windows, LPE до SYSTEM, CVSS v4 7.3
Механизм: когда админ открывает агент с повышенными правами, служба VeeamEndpointBackupSvc выдаёт идентификатор сессии. Этот идентификатор пишется открытым текстом в лог, который читают все пользователи машины. Любой, кто его прочитал, может предъявить его службе и выполнять команды как SYSTEM.
Уязвимы: сборки 13.0.2.1102 и ниже
Исправлено: 13.0.3.1220+ (актуальная standalone-версия — 13.1.1.700)
Публичный PoC: с 14 сентября

ЧТО НЕ ФАКТ:
Arctic Wolf сообщил об активной эксплуатации, а затем убрал бюллетень. В бюллетене самого Veeam упоминаний эксплуатации нет, в CISA KEV на момент написания уязвимости тоже нет.
Подтверждённой эксплуатации нет. Но публичный PoC для локальной LPE — это вопрос недель, а не месяцев.

УСЛОВИЯ АТАКИ:
• локальный доступ к машине
• админ хотя бы раз открыл агент с повышенными правами, и сессия активна
Самые рискованные машины — терминальные серверы и общие рабочие станции, где много пользователей и сидит агент.

# Версия агента на машине
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' |
? DisplayName -like '*Veeam Agent*' | Select DisplayName, DisplayVersion

# По списку серверов
$srv = Get-Content .\servers.txt
Invoke-Command -ComputerName $srv -ScriptBlock {
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' |
? DisplayName -like '*Veeam Agent*' | Select DisplayName, DisplayVersion
} | Select PSComputerName, DisplayName, DisplayVersion

КАК ОБНОВЛЯТЬ:
Standalone → 13.1.1.700
Агенты под управлением VBR → сначала VBR до 13.0.2.29+, затем убедиться, что агенты реально обновились. Обновление VBR само по себе не означает обновлённых агентов.

Итог: «эксплуатируется» здесь — неподтверждённое утверждение, а публичный PoC и тривиальный механизм — факт. Для решения хватает второго: обновляем, начиная с RDS-хостов.

#skills #veeam #backup #cve #lpe #sysadmin #admin_future