29.04.2026 22:02
🔐 15 лет с голой жопой.
🔐 15 лет с голой жопой. Как обычная запятая в OpenSSH давала root-права всем желающим.
Безопасники из компании Cyera раскопали эпичный факап в самом сердце опенсорса. В коде 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 (вышел в начале апреля). Так что, господа, идем чекать версии демонов sshd и обновляем пакеты. И заодно проверьте, кому ваш внутренний Vault/CA раздает серты, пока кто-нибудь не зашел на прод под логином user,root 🙂
💾Обсудить можно в Чате ИТ
Безопасники из компании Cyera раскопали эпичный факап в самом сердце опенсорса. В коде 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 (вышел в начале апреля). Так что, господа, идем чекать версии демонов sshd и обновляем пакеты. И заодно проверьте, кому ваш внутренний Vault/CA раздает серты, пока кто-нибудь не зашел на прод под логином user,root 🙂
💾Обсудить можно в Чате ИТ