В Linux обнаружили новую дыру уровня «потом разберемся, как именно нас вынесли». Уязвимость Linux с идентификатором CVE-2026-46333 затрагивает все ядра, выпущенные до 14 мая 2026 года, и при удачном сценарии позволяет локальному пользователю читать SSH host private keys и содержимое shadow-файла. Для админов, DevOps-команд и тех, кто держит парк серверов на нескольких дистрибутивах, это неприятная новость: патч уже есть, но до большинства систем он доедет не мгновенно.
О проблеме сообщает ZDNet со ссылкой на исследователей Qualys. В самой Linux-экосистеме уязвимость уже получила неофициальное имя ssh-keysign-pwn — по одному из самых заметных путей эксплуатации через вспомогательный бинарник OpenSSH ssh-keysign. Этот компонент используется для host-based authentication и обычно запускается с setuid root: сначала открывает системные SSH-ключи, а потом сбрасывает привилегии. Именно в такой переходный момент и появляется окно, которым может воспользоваться атакующий.
Технически речь идет об ошибке раскрытия информации в проверке доступа ptrace внутри ядра Linux. По данным Qualys, баг в том или ином виде мог существовать около шести лет. Проблемный участок находится в логике __ptrace_may_access(), которая срабатывает, когда процесс завершает работу. В ряде условий ядро пропускает стандартную проверку dumpable после того, как процесс уже избавился от своей memory mapping. В результате другой процесс может перехватить все еще открытые файловые дескрипторы привилегированного процесса. А дальше начинается то, что безопасники обычно называют не «полным компромиссом», а «очень удобным строительным блоком» для него.
Сама по себе эта уязвимость Linux не выдает атакующему root-shell на блюдце. Но кража закрытых SSH-ключей хоста и хэшей паролей из shadow — это уже материал для lateral movement, долговременного закрепления и офлайн-подбора паролей. Если злоумышленник получает host keys, он может выдавать себя за доверенную машину в инфраструктуре с host-based trust. Если добирается до shadow, появляется шанс спокойно брутфорсить хэши вне продакшена, без шума и без ограничений по rate limit. Для компаний это особенно неприятный класс риска: инцидент может начаться с локального доступа на одной машине, а закончиться проблемами в нескольких сегментах сети.
Отдельно тревожит не только сам баг, но и частота таких историй. ZDNet называет CVE-2026-46333 уже четвертой заметной проблемой в Linux kernel за месяц. Это не значит, что Linux внезапно стал «дырявым», а остальные платформы — образцом аскезы и безопасности. Но это хороший холодный душ для команд, которые до сих пор мыслят в стиле «ядро обновим на следующем окне, ничего страшного». Когда подряд всплывают несколько high-profile уязвимостей, даже локальные баги перестают быть локальной головной болью. Они начинают влиять на график релизов, политику hardening, процессы инвентаризации хостов и правила доступа на рабочих станциях разработчиков.
Хорошая часть новости в том, что исправление уже выпущено. Поддерживающий stable-ветки Linux Грег Кроа-Хартман развернул обновления сразу для нескольких поддерживаемых линий ядра. Исправление включено, в частности, в версии 7.0.8, 6.18.31, 6.12.89, 6.6.139, 6.1.173, 5.15.207 и 5.10.256. Плохая часть предсказуема: наличие патча в upstream еще не означает, что ваш конкретный дистрибутив уже подготовил, протестировал и раскатал пакет. Между релизом исправления и его появлением в репозиториях Ubuntu, AlmaLinux, Rocky Linux, openSUSE, Mint или корпоративных сборках почти всегда есть лаг. А именно в этом промежутке уязвимость Linux становится задачей не для разработчиков ядра, а для тех, кто отвечает за реальные машины.
Временные меры есть, но все они с подвохом. Самый прямой обходной путь — ужесточить ограничения Yama для ptrace командой sysctl kernel.yama.ptrace_scope=2. Это блокирует эксплуатацию для непривилегированных пользователей, но одновременно ломает часть привычных сценариев отладки и мониторинга. Для workstation-разработки, SRE-инструментов и некоторых диагностических пайплайнов это может оказаться слишком дорогой защитой. Второй вариант — отключить host-based SSH authentication и сам ssh-keysign там, где они не нужны. Идея здравая: убираем один из главных каналов кражи ключей. Проблема в том, что в ряде инфраструктур SSH — это не «удобный сервис», а основа доступа, автоматизации и операционной рутины. Отключать его без понимания зависимостей — быстрый способ устроить себе инцидент уже собственными руками.
Для русскоязычной IT-аудитории практический вывод довольно земной. Во-первых, стоит проверить, какие версии ядра реально крутятся на серверах, jump hosts, CI-агентах и разработческих машинах, а не какие «должны быть по регламенту». Во-вторых, нужно смотреть не только на наличие апдейта в upstream, но и на статус пакетов у конкретного вендора дистрибутива. В-третьих, имеет смысл заранее понимать, где в инфраструктуре используется host-based authentication и нужен ли там вообще ssh-keysign. Это тот случай, когда инвентаризация и минимизация поверхности атаки приносят больше пользы, чем очередной красивый дашборд с зеленым статусом.
История с CVE-2026-46333 снова показывает простую вещь: безопасность Linux все меньше похожа на мир, где можно спокойно жить на репутации платформы, и все больше — на обычную инженерную дисциплину с жестким SLA на обновления и понятной моделью рисков. Уязвимость Linux, которая позволяет вытаскивать SSH-ключи и парольные хэши в момент завершения привилегированного процесса, — не апокалипсис, но очень внятный сигнал. В ближайшие месяцы выиграют не те команды, которые громче рассказывают про hardening, а те, кто умеет быстро дотягивать kernel fixes до продакшена и не держит в системе лишних доверительных механизмов «на всякий случай».
The post Новая уязвимость Linux позволяет красть SSH-ключи до установки патча appeared first on iTech News.