Уязвимость в OpenSSH: имена пользователей позволяют выполнить код

Уязвимость в OpenSSH: имена пользователей позволяют выполнить код

Уязвимость в OpenSSH: имена пользователей позволяют выполнить код

Исследователь безопасности Дэвид Лидбитер обнаружил уязвимость в OpenSSH — CVE-2025-61984 — которая демонстрирует: даже мелкие особенности парсинга команд и поведения shell могут привести к удалённому выполнению кода.

Суть проблемы проста и неприятна: в OpenSSH (до версии 10.1) контрол-символы в именах пользователей, полученных из ненадёжных источников, могли не отфильтровываться.

Когда такое «имя» подставлялось в ProxyCommand (через переменную %r), OpenSSH формировал строку для exec, которую запускал через shell. Если в этой строке оказывались символы вроде $[ и символы новой строки, некоторые оболочки (например, bash) могли интерпретировать это так, что первая команда аварийно завершается, а затем выполняется то, что идёт после — то есть возможна инъекция команды.

Эксплуатация требует специфической связки: конфигурация, использующая ProxyCommand с %r, уязвимая оболочка и «входной» источник имени пользователя, который злоумышленник контролирует. Практический пример — злоумышленный .gitmodules, где в URL подставляют строку вроде:

[submodule "foo"]
  path = foo
  url = "$[+]\nsource poc.sh\n@foo.example.com:foo"

Если SSH-конфиг содержит строку вроде

ProxyCommand some-command %r@%h:%p

и вы запускаете git clone --recursive, то в подходящих условиях может выполниться source poc.sh — до установления самого соединения.

Важно понимать: условия для успешной атаки нишевые, но реальны — инструментальная цепочка Git → SSH → shell и автоматизация (CI/CD) дают атакующему много точек входа. Проблема усугубляется тем, что OpenSSH фильтровал многие метасимволы, но пропустил $ и [ — и это создало неожиданный вектор.

Исправление уже включено в OpenSSH 10.1: разработчики начали проверять и запрещать управляющие символы в именах пользователей через iscntrl() в ssh.c. То есть долгосрочное решение — обновиться до 10.1 или новее.

Если обновиться сразу нельзя, Лидбитер предлагает два практических временных шага. Во-первых, брать имя пользователя в одинарные кавычки в ProxyCommand, чтобы предотвратить подстановку:

ProxyCommand some-command '%r@%h:%p'

(Обратите внимание: одинарные кавычки нужны именно потому, что двойные не защитят от $[ — оболочка всё ещё будет их обрабатывать.) Во-вторых, по умолчанию отключить SSH-подмодули в Git и не позволять автоматические URL-хендлеры, которые могут передавать непроверенные SSH-команды:

git config --global protocol.ssh.allow user

Главный вывод — не полагаться на то, что «маленький» символ или строка не принесут беды: при передаче входа от ненадёжных источников через несколько инструментов даже неочевидная каверза в парсинге может стать критической. Рекомендуется как можно скорее обновить OpenSSH или применить временные защитные меры в конфигурациях ProxyCommand и политиках Git.

Windows 11 начнёт автоматически включать усиленную защиту ядра с октября

Microsoft с октября 2026 года начнёт включать функцию «Целостность памяти» по умолчанию на совместимых устройствах с Windows 11. Сейчас этот механизм уже присутствует в системе, но часто требует ручной активации. Скоро Windows Update сделает всё сам — редкий случай, когда внезапная смена настройки должна повысить безопасность.

«Целостность памяти», также известная как Hypervisor-protected Code Integrity (HVCI), работает на базе защиты с использованием виртуализации (VBS).

Система создаёт изолированную среду и разрешает запускать в режиме ядра только доверенный код и драйверы. Это осложняет атаки, при которых вредоносные программы используют уязвимые или подменённые драйверы для захвата компьютера на низком уровне.

Изменение будут распространять вместе с ежемесячными обновлениями качества Windows. Ожидается, что первая волна начнётся с октябрьского Patch Tuesday, запланированного на 13 октября. При активации HVCI операционная система также включит VBS.

Перед изменением настроек Windows проведёт проверку готовности устройства. Это должно снизить риск проблем с несовместимыми драйверами или оборудованием.

ИТ-администраторы сохранят контроль над функцией. Если организация намеренно отключила «Целостность памяти» с помощью политик или существующей конфигурации безопасности, Windows Update не станет включать её обратно. Остальные совместимые компьютеры постепенно получат новый базовый уровень защиты автоматически.

Microsoft объясняет решение желанием сократить объём ручной настройки и подготовить Windows к следующему поколению защитных механизмов.

RSS: Новости на портале Anti-Malware.ru