![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Красота, 15 лет
https://t.me/sysodmins/28827
15 лет с голой жопой. Как обычная запятая в OpenSSH давала root-права всем желающим.
Безопасники из компании Cyera раскопали (https://www.cyera.com/blog/a-15-year-gap-in-ssh-security---and-what-to-do-about-it) эпичный факап в самом сердце опенсорса. В коде OpenSSH нашли дыру (CVE-2026-35414), которая 15 лет позволяла получить рута через... банальную опечатку.
Баг благополучно жил в кодовой базе полтора десятилетия. Эксплойт позволяет любому юзеру с низкими привилегиями, имеющему валидный серт от доверенного центра сертификации, инстантно поднять свои права до root на целевом сервере
Для тех кто позабыл... SSH-сертификаты работают через principals (роли/имена), которые прописываются при подписи ключа утилитой ssh-keygen. Сервер при коннекте сверяет эти principals со своим локальным конфигом.
А теперь следите за руками разработчиков OpenSSH. Какой-то сумрачный гений 15 лет назад решил сэкономить время и заюзал для парсинга списка principals старую сишную функцию, которая изначально писалась для парсинга списков алгоритмов шифрования (в духе aes128-ctr,aes256-gcm).
Для этой функции запятая - это истинный разделитель массива. Что делает атакующий? Он просит у своего CA выпустить сертификат с принципалом, в имени которого тупо захардкожена запятая. Например deploy,root.
Что делает уязвимый OpenSSH-сервер? Он берет эту строку, прогоняет через кривой парсер, который сплитит её на два отдельных принципала: deploy и root. Дальше срабатывает логическая дыра... первая функция проверки видит совпадение по deploy (если такой юзер разрешен сервером) и пускает дальше, а вторая функция авторизации из-за конфликта переменных просто скипает дальнейшую валидацию и... выдает атакующему полноценный root. Epic Win! На написание рабочего эксплойта у исследователей ушло 20 минут.
Самая жопа заключается в том, что этот взлом физически невозможно отследить по логам. Поскольку сервер технически считает авторизацию легитимной (сертификат-то валидный, криптография сошлась, подпись CA верна), в /var/log/auth.log не падает никаких ошибок authentication failure. Никакие Fail2Ban, Wazuh и дорогущие SIEM-системы на это не триггернутся. В логах это выглядит как штатный, рутинный логин легального юзера
Патч уже выкатили в свежем релизе OpenSSH 10.3 (https://www.openssh.org/) (вышел в начале апреля). Так что, господа, идем чекать версии демонов sshd и обновляем пакеты. И заодно проверьте, кому ваш внутренний Vault/CA раздает серты, пока кто-нибудь не зашел на прод под логином user,root
15 лет с голой жопой. Как обычная запятая в OpenSSH давала root-права всем желающим.
Безопасники из компании Cyera раскопали (https://www.cyera.com/blog/a-15-year-gap-in-ssh-security---and-what-to-do-about-it) эпичный факап в самом сердце опенсорса. В коде OpenSSH нашли дыру (CVE-2026-35414), которая 15 лет позволяла получить рута через... банальную опечатку.
Баг благополучно жил в кодовой базе полтора десятилетия. Эксплойт позволяет любому юзеру с низкими привилегиями, имеющему валидный серт от доверенного центра сертификации, инстантно поднять свои права до root на целевом сервере
Для тех кто позабыл... SSH-сертификаты работают через principals (роли/имена), которые прописываются при подписи ключа утилитой ssh-keygen. Сервер при коннекте сверяет эти principals со своим локальным конфигом.
А теперь следите за руками разработчиков OpenSSH. Какой-то сумрачный гений 15 лет назад решил сэкономить время и заюзал для парсинга списка principals старую сишную функцию, которая изначально писалась для парсинга списков алгоритмов шифрования (в духе aes128-ctr,aes256-gcm).
Для этой функции запятая - это истинный разделитель массива. Что делает атакующий? Он просит у своего CA выпустить сертификат с принципалом, в имени которого тупо захардкожена запятая. Например deploy,root.
Что делает уязвимый OpenSSH-сервер? Он берет эту строку, прогоняет через кривой парсер, который сплитит её на два отдельных принципала: deploy и root. Дальше срабатывает логическая дыра... первая функция проверки видит совпадение по deploy (если такой юзер разрешен сервером) и пускает дальше, а вторая функция авторизации из-за конфликта переменных просто скипает дальнейшую валидацию и... выдает атакующему полноценный root. Epic Win! На написание рабочего эксплойта у исследователей ушло 20 минут.
Самая жопа заключается в том, что этот взлом физически невозможно отследить по логам. Поскольку сервер технически считает авторизацию легитимной (сертификат-то валидный, криптография сошлась, подпись CA верна), в /var/log/auth.log не падает никаких ошибок authentication failure. Никакие Fail2Ban, Wazuh и дорогущие SIEM-системы на это не триггернутся. В логах это выглядит как штатный, рутинный логин легального юзера
Патч уже выкатили в свежем релизе OpenSSH 10.3 (https://www.openssh.org/) (вышел в начале апреля). Так что, господа, идем чекать версии демонов sshd и обновляем пакеты. И заодно проверьте, кому ваш внутренний Vault/CA раздает серты, пока кто-нибудь не зашел на прод под логином user,root
no subject
no subject
no subject
Я когда-то подбирал приличную библиотеку, чтоб использовать для "надёжной идентификации" Выяснил, что подпись заверяется чем-то вроде "мамой клянусь, это моя айдентити, я её сам подписал".
Но у Сейлсфорса всё было надёжно имплементировано.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
И, кто знает, те в дыру ходят.
И так, чтобы по логам тоже виновных не установить было.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Вот с этого места не понял. Почему она ему выдаёт полноценный root?
no subject