CVE-2023-51385
OpenSSH ssh: инъекция команд через пользовательские имена
CVE-2023-51385 касается ssh, когда недоверенное имя пользователя или хоста проходит через %u/%h в ProxyCommand, LocalCommand либо Match exec. OpenSSH 9.6 добавил фильтрацию shell-метасимволов; проверяйте также собственную оболочку и конфигурацию.
Кому нужно проверить
Администраторам рабочих станций и автоматизации, где ssh вызывается с пользовательскими именами или именами узлов и нестандартными shell-командами. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
При уязвимом quoting недоверенное имя может изменить shell-команду, выполняемую локальным ssh-клиентом. Последствия зависят от прав пользователя и команд, заданных в ssh_config; это клиентская проблема, а не удалённое выполнение кода в sshd.
Затронутые версии
OpenSSH до 9.6 может быть уязвим, если атакующий контролирует переданное ssh имя пользователя/хоста, оно содержит shell metacharacters, а пользовательская ssh_config использует соответствующее раскрытие в ProxyCommand, LocalCommand или Match exec. Результат зависит от quoting в конфигурации; один лишь запуск ssh не доказывает применимость.
Исправленные версии
OpenSSH 9.6 добавил фильтрацию недопустимых символов в именах пользователя и хоста, передаваемых в shell-контексты. Обновите клиент до актуальной исправленной версии и проверьте локальные конфигурации; OpenSSH отмечает, что даже исправление не отменяет необходимость безопасного quoting в пользовательских командах.
Что сделать
- 1Проверьте версию OpenSSH и вызовы ssh, в которых user/host формируются из внешних данных, CI-параметров или пользовательского ввода.
- 2Обновите OpenSSH до 9.6 или новее. Сопоставьте изменения с пакетной версией и подтвердите, что автоматизация вызывает именно исправленный бинарный файл.
- 3Просмотрите ProxyCommand, LocalCommand и Match exec в системной и пользовательской ssh_config. Не вставляйте непроверенные имена в shell; используйте надёжное quoting и разрешённый список хостов/пользователей.
- 4Проверьте штатные подключения и автоматизацию на тестовой среде. Убедитесь, что логи и конфигурации не содержат секретов, и расследуйте неожиданное выполнение локальных команд в период до обновления.
Проверка командной подстановки в ssh
Уязвимость требует внешне контролируемого имени и shell-контекста.
- 1Проверить источники user/host
- 2Найти shell-команды в ssh_config
- 3Обновить клиент и исправить quoting
- 4Проверить автоматизацию
Примеры конфигурации и проверки
grep -nE '^(ProxyCommand|LocalCommand|Match)' ~/.ssh/configНа Unix-системе команда только читает указанный файл. Повторите поиск в системном ssh_config и Include-файлах; совпадение не доказывает уязвимость без проверки раскрытий %u/%h и quoting. Не публикуйте конфигурацию, если в ней есть внутренние имена или секретные параметры.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.