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

Роскомнадзор начал массовые проверки сайтов на соответствие 152-ФЗ

Роскомнадзор начал массово проверять сайты российских организаций на соответствие требованиям законодательства о защите персональных данных. Для этого регулятор использует специального бота, который автоматически ищет возможные нарушения. Судя по предписаниям, такие проверки позволяют выявлять больше несоответствий, чем прежний ручной контроль.

Юрист Алексей Башук в своём блоге на Хабре связывает резкую активизацию регулятора с изменениями в законодательстве, которые вступили в силу осенью 2025 года.

Если ещё в ноябре 2025 года такие проверки были единичными, то теперь Роскомнадзор разработал специального бота для автоматизированного сбора данных о нарушениях. По словам эксперта, он работает постоянно.

Если бот выявляет возможные несоответствия, материалы передают сотруднику Роскомнадзора. Тот проверяет сайт уже вручную и при подтверждении нарушений выдаёт предписание. На их устранение организации дают всего 10 дней.

При этом выросли и штрафы. Как напоминает эксперт, неуведомление регулятора о сборе персональных данных или их обработка без согласия пользователя могут обернуться штрафом от 100 тыс. до 300 тыс. рублей.

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

К нарушениям относят, например, простое размещение ссылок на документы без подтверждения ознакомления пользователя, а также предустановленные галочки согласия. При этом если пользователь должен поставить галочку самостоятельно, такой порядок регулятора уже устраивает.

Роскомнадзор также сверяет компании с реестром операторов персональных данных. Если организация обрабатывает персональные данные, но отсутствует в реестре, регулятор рассматривает это как неуведомление, то есть как нарушение. Кроме того, проверяется содержание обязательных документов, где также часто находят ошибки.

Отдельная проблема — веб-аналитика. Владельцы сайтов нередко забывают, что её использование считается сбором персональных данных, о котором нужно предупреждать пользователей. А использование сервисов Google может трактоваться как передача персональных данных в недружественную страну.

Распространены и нарушения, связанные с публикацией фотографий сотрудников. Если на сайте нет подтверждения согласия на размещение таких материалов и запрета для третьих лиц использовать эти данные, Роскомнадзор также может счесть это нарушением.

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