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


Телеграм: t.me/ainewsline

Источник: vk.com

Комментарии: