Красота, 15 лет

[mdmx]

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

Comments

[frozen_cat]

Мда..

[juan_gandhi]

Забавно. Интересно это всё у них.

Я когда-то подбирал приличную библиотеку, чтоб использовать для "надёжной идентификации" Выяснил, что подпись заверяется чем-то вроде "мамой клянусь, это моя айдентити, я её сам подписал".

Но у Сейлсфорса всё было надёжно имплементировано.

[vit_r]

Очень похоже на закладку.

[brumka]

Как такое вообще нашли?.. обязательно почитаю попозже, спасибо

[kondybas]

бляяяя

[cmpax_u_pagocmb]

>>первая функция проверки видит совпадение по deploy (если такой юзер разрешен сервером) и пускает дальше, а вторая функция авторизации из-за конфликта переменных просто скипает дальнейшую валидацию и... выдает атакующему полноценный root.<<

Вот с этого места не понял. Почему она ему выдаёт полноценный root?

[mdmx]

Вопросы можно задавать автору текста по ссылке сверху на источник новости

[mdmx]

А сколько такого еще не вскрытого лежит

[mdmx]

Наличие ошибки неизбежно, это математика. А вот наличие знания о ней это совсем другой вопрос.

[mdmx]

Ну не думаю. Слишком долго тогда продержалось. Скорее действительно ошибка про которую не знали.

[mdmx]

Анализ исходников с помощью ии

[mdmx]

Ага, сколько такого еще впереди

[vit_r]

Хорошая закладка так и работает. Тут немножко недопроверили. Там немножко переповерили. Здесь передали без проверки.

И, кто знает, те в дыру ходят.

И так, чтобы по логам тоже виновных не установить было.

[juan_gandhi]

Ну вообще-то, или Lean, или TLA+ могли бы помочь формально всё верифицировать. Но нужно исключить какое-либо доверие к библиотекам (или верифицировать и их).

[brumka]

ну, тада понятно. такие баги вылавливать традиционными методами практически нереально

[mdmx]

Реально но не с человеческими силами и ресурсами

[brumka]

видимo, очень много работы (т.е. дорого) дабы настолько серьёзно подходить к проверкам. особенно, для opensource.

[mdmx]

Впереди нас ждет увлекательный шторм ревизий, и думаю что не многое на самом деле будет на слуху. Что стоит анализ исходников инваермента ПО конкурента из сорсов при помощи ИИ для достижения поставленной цели.