Уязвимость в 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.

0-day в Office уже используют в атаках: Microsoft спешно закрывает дыру

Microsoft снова пришлось экстренно латать дыры. Компания выпустила внеплановые патчи для Microsoft Office, закрывающие опасную уязвимость нулевого дня, которую уже используют в атаках. Проблема получила идентификатор CVE-2026-21509 и затрагивает сразу несколько версий офисного пакета: Office 2016, Office 2019, Office LTSC 2021 и 2024, а также Microsoft 365 Apps for Enterprise.

Уязвимость позволяет обойти защитные механизмы Office, отвечающие за блокировку опасных COM/OLE-компонентов.

Атака при этом довольно тривиальная: злоумышленнику достаточно отправить пользователю вредоносный документ и уговорить его открыть файл. Без участия человека не обойтись, но технически всё выглядит максимально просто.

Хорошая новость в том, что пользователи Office 2021 и более новых версий уже автоматически защищены — Microsoft закрыла дыру на стороне сервиса. Правда, изменения вступят в силу только после перезапуска приложений Office. А вот владельцам Office 2016 и 2019 пока не повезло: патчи для этих версий ещё не готовы, и компания обещает выпустить их «в ближайшее время».

Чтобы хоть как-то снизить риск, Microsoft предложила временное решение — ручную настройку через реестр Windows. Мера выглядит запутанно, но по сути сводится к добавлению специального флага совместимости для уязвимого COM-компонента.

После этого защита начинает работать при следующем запуске Office. В компании отдельно подчёркивают: перед редактированием реестра лучше сделать резервную копию, иначе можно нажить проблем больше, чем было.

Никаких подробностей о том, как именно эксплуатируется уязвимость и кто её обнаружил, Microsoft раскрывать не стала. Впрочем, история вполне укладывается в общий фон января: в рамках Patch Tuesday 2026 года компания уже закрыла 114 уязвимостей, включая ещё одну активно эксплуатируемую 0-day, а заодно выпустила несколько внеплановых обновлений из-за багов в Windows и Outlook.

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