Компания Qualys выявила удалённо эксплуатируемую уязвимость (CVE-2023-38408) в реализации ssh-agent из состава OpenSSH, позволяющую выполнить код в системе, предоставившей доступ к ssh-agent для хоста на другом конце ssh-соединения. Совершение атаки возможно только если пользователь подключился по ssh к системе, контролируемой злоумышленником, включив проброс сокета к ssh-agent по ssh при помощи опции "-A" или настройки ForwardAgent в файле конфигурации. Кроме того, для успешной атаки в системе жертвы должны присутствовать определённые библиотеки. Исследователями подготовлены прототипы эксплоитов, работа которых продемонстрирована в Ubuntu 22.04 и 21.10...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59469
В OpenBSD опять скажут что ни одной уязвимостиГ
Конечно, у нас же нет этих некоторых библиотек!
И вообще мы компьютеры редко включаем
Вы да, а вот те кто берут(брали) опен за основу своих поделок работают фуллтайм ещё возможно в критических сферах.
> возможно в критических сферахНапример, в каких?
Тео де Раадт работает ровно в одной критической сфере: поддержка кода OpenSSH. За это ему дают достаточно денег, чтобы играть в разработчка операционной системы общего назначения (но недостаточно, чтобы платить за электричество для своих игрушек). А кто ещё?
> В OpenBSD опять скажут что ни одной уязвимостиГПричем тут OpenBSD если работа дыры продемонстрирована на Debian? И зависит целиком от дыры в Debian, описанной дальше по тексту.
У оголтелых как обычно - увидали уязвимость в проектах *BSD, и тут же комментарий строчить, даже новость до конца не дочитав.
И как обычно очередной раз об*ристаться жиденько.
> даже новость до конца не дочитав.И чем бы им чтение до конца помогло?
Знание о том, что /usr/lib и /usr/local/lib кое-где - две большие разницы (а не "это симлинк, а это вообще не нужно, немолодежно и вообще, давайте просто все свалим в одну большую кучу") все равно не появится.
Не расскажешь, в чём же концептуальная разница между /usr/lib и /usr/local/lib? Особенно в контексте данной дыры интересно послушать.
Тем, что в OpenBSD OpenSSH не лезет в /usr/local/lib, где живёт какая-то либа от постгреса? Предвосхищу вопрос. В /usr/lib/ живут библиотеки, которые отвечают требованиям разработчиков ОС и многие финты ушами не могут исполнить впринципе.
https://cvsweb.openbsd.org/src/usr.bin/ssh/ssh-agent.c?rev=1...
> Изначально возможность загрузки разделяемых библиотек
> не рассматривалась как угроза безопасностиЭто серьезно? Дорогие безопаснички из openbsd, вы про attack surface слышали? А, вот, теперь уж точно услышите!
Да ваще! Доколе?! Совсем распоясались, не то что ты - прочитал чужую статью и сразу стал указывать openbsd'шникам как им делать.Ты где раньше то был? Почему пишешь про это только, когда эта статья уже появилась и была переведена на русский?
Да им и двадцать лет назад предлагалось [роскомнадзор] - на охоту там сходить или еще как стать героями, и прекратить загаживать поляну.Без всякой необходимости чего-то там переводить на русский.
P.S. ну и еще один привет йуным любителям сложить все ключи от всего кучкой.
> P.S. ну и еще один привет йуным любителям сложить все ключи от всего кучкой.Хехе, именно поэтому у меня есть то что я условно называю "management VMs". Во множественном числе. Случаи бывают разные - так что на всякий случай я лучше врублю силовые щиты, а там посмотрим понадобятся они или это перестраховка. С вон теми безопасничками кажется нифига оно не перестраховка :)
> Ты где раньше то был? Почему пишешь про это только, когда эта статья уже
> появилась и была переведена на русский?Я по-моему сто лет назад написал что openssh стал монструозным Г делающим слишком много побочной хни и при этом не очень хорошо выполняя свою основную функцию. Потому что защита секурити и приваси шелла у него не очень хорошо получается, там на уровне крипто проблемы и вообще.
> Потому что защита секурити и приваси шелла у него не очень хорошо получается, там на уровне крипто проблемы и вообще.А пруфы будут?
>> каталогов /usr/lib*
> Это серьезно? Дорогие безопаснички из openbsd, вы про attack surface слышали? А, вот, теперь уж точно услышите!Они - возможно, а вот пингвинята, свалившие все в одну большую помойку - точно нет.
> Они - возможно, а вот пингвинята, свалившие все в одну большую помойку - точно нет.Мне почему-то очень соблазнительно назвать сам OpenSSH одной большой помойкой. Поразвели всяких агентов и супернужной хни с 120 лезвиями на все случаи жизни, бжад, и теперь удивляются.
>> Изначально возможность загрузки разделяемых библиотек
>> не рассматривалась как угроза безопасности
> Это серьезно? Дорогие безопаснички из openbsd, вы про attack surface слышали? А,
> вот, теперь уж точно услышите!Я слышал от майнтайнеров по сборке пакетиков в GNU/Linux, что они всё исправляют за "тупыми программистами" (ц)
> Я слышал от майнтайнеров по сборке пакетиков в GNU/Linux, что они всё
> исправляют за "тупыми программистами" (ц)А куда они денутся с подводной лодки? Вот чем-то таким им сейчас и придется заняться в темпе вальса.
Если компонент спроектирован для OpenBSD, и в составе той системы "уязвимость" не эксплуатируется, то это ещё вопрос: ошибся ли автор, или намеренно показал миру суть халявщиков, кто сейчас побежит искать патчики, называя это "исправлять".
>Я слышал от майнтайнеров по сборке пакетиков в GNU/Linux, что они всё исправляют за "тупыми программистами" (ц)У меня при этих звуках вспоминается как "умные мэинтайнеры" демьяна исправили за "тупыми программистами" неинициализированную память, и (как хорошие нынешние мальчики-ржавчики) заполнили еЯ нулями ... Ж:-D :-)))
Ух, знатно тогда норот(С) офигел, когда их ключи можно было на бумажке, "в столбик" отреверсить :-DDDD
А ведь это классика. Так кейгенили RSA2048 в ASProtect.
Типично для проектов OpenBSD, к сожалению.
А теперь повторите тот же самый эксплойт на OpenBSD))
На овнолинухе он работает.
> А теперь повторите тот же самый эксплойт на OpenBSD))
> На овнолинухе он работает.Типично для фанбоев, увы. То, что 1 в 1 не работает, или даже дыра заткнута чем-то другим, не уменьшает серьёзность проблемы. К тому же, на openbsd этим никто не пользуется, приоритеты должны быть расставлены верно.
> Типично для фанбоев, увы. То, что 1 в 1 не работает, или даже дыра заткнута чем-то другимТипично для пингвинячих фанбоев, сделавших из /usr/lib* одну большую мусорную кучу (все, как в любимой венде) вместо хранения лишь системных библиотек, обвинять других, увы.
тоочна! Вот если в системе нет библиотек - она ниувизгвима! (правда еще и делать толком ничего не может, но это опен6cдунов не пугает, они ж и не собирались. Вещь законченная, как корабль в бутылке - поставить на полочку и любоваться. Включать тоже не рекомендуется.)
Типично для проектов го*нопортируемых в пингвинячий дуршлаг.....
> Типично для проектов го*нопортируемых в пингвинячий дуршлаг.....Ну говори тогда уж полностью *но проектов *нарей *нопопртируемых из *на в популярную систему, а то как-то однобоко.
интересный тесткейс )
Панику развели. Часто подсоединяетесь к хостам, контролируемые злоумышленниками? Планово обновить системы и всё. Дыры в безопасности неприятны и опасны, особо которые remote, но не эта проблема.
При целевых атаках сработает имхо, e.g. кто-то контролирует скажем вайфай или путь до сервера. Много людей сравнивают отпечатки при соединении когда ssh ругается?
> Много людей сравнивают отпечатки при соединении когда ssh ругается?Так они пожалуй введут свои кренделя и зальют ключи на немного посторонний хост. Может вы вон туда еще и биткоин кошель закинете? :)
Если ругается внезапно, а не в ожидаемый момент (когда только что сгенерил новые ключи)? Не то, что в ожидаемый момент не может быть атаки - может, и это идеальный вариант для атакующего, почти все поленятся в такой ситуации сравнивать отпечатки. Но когда это произойдет внезапно - это каким же кретином надо быть, чтобы это проигнорировать?
тебе, дypaчку _одного_ раза хватит.
Планово обновлять очень тебе поможет от зеродея.Или просто от т-пого разработчика, ОПЯТЬ, да что ж такое, при попытке открыть загруженную пользователем картинку ее выполнившего в точном соответствии со спецификацией на какой-то там неведомый тебе phar:// или %pipe%
И вот ты зашел на один свой хост - а он немного уже и не твой. И пока ты это заметишь (а с твоими талантами пройдет - вечность) - не твоими станут ВСЕ твои хосты, потому что перехватят управление твоим локалхостом где ты бережно сложил ключи от всего.
Часто ли хост при подключении выдаёт баннер "Данный хост контролируется злоумышленниками"?
хм... вообще-то идея плодотворная... взял на заметку.
Так это тоже не поможет.
Разве что шрифт 48-го размера поставить (как?).
Много ли народу смотрит когда был last login
Даже не смотря на то, что это последняя строка вывода при входе на хост.
Так опенбсд работает на сами знаете кого это уже лет 20 как всем известно.
> Для эксплуатации уязвимости выполняются следующие манипуляции:
> ...
> Загружается несколько
> Загружается библиотека
> Загружаются библиотеки
> Загружается библиотека
> Загружаются библиотеки дляСразу рута дайте, чо мучаться.
> ... официально поставляемые дистрибутивом библиотеки, а операции с данными библиотеками
> ограничены вызовом функций dlopen() и dlclose(), без обращения к функциям библиотек.Чот уйню написали. Ну сделал я dlopen() /usr/lib/libGL.so.1 нафуя она мне без функции из неё?
lib = dlopen();
if (!lib)
return;sym = dlsym(lib, "keklol");
if (!sym) {
dlclose(lib);
return;
}
> sym = dlsym(lib, "keklol");А теперь ещё раз прочти "ограничены вызовом функций dlopen() и dlclose()"
Переводчеги, переводите ещё раз.
Although this seems safe at first (because every shared library in /usr/lib* comes
from an official distribution package, and no operation besides dlopen() and dlclose()
is generally performed by ssh-agent on a shared library), many shared libraries have
unfortunate side effects when dlopen()ed and dlclose()d, and are therefore unsafe
to be loaded and unloaded in a security-sensitive program such as ssh-agent.
For example, many shared libraries have constructor and destructor functions that
are automatically executed by dlopen() and dlclose(), respectively.Речь о о том, что ssh-agent ничего не делает с библиотеками кроме dlopen() и dlclose()
> Чот уйню написали. Ну сделал я dlopen() /usr/lib/libGL.so.1 нафуя
> она мне без функции из неё?Что тебе не нравится? Загрузил либу? Молодец, протри с нее пыль и положи обратно dlclose'ом. Вот и поработал с либами.
Давно хотел задать вопрос, темы не было. А если удалить с локального хоста всю криптографию, то шифровальщики смогут мне хомяка зашифровать?
Желательно получить ответ на этот вопрос, а не интерпретации "скажи отцу, что б впредь предохранялся".
Они с собой приносят, чтобы нне полагаться на хост. Мало ли у тебя библиотека старая.
Реализовать функцию криптографического преобразования - это уровень лабораторной работы студента профильной специальности. Взять готовые исходники, не понимая, что там написано, собрать и продать - это уровень "разработчиков" дистрибутивов.
OpenBSD-7.3, вчера прилетел syspatch для ssh-agent.. читаю.. ну, ок:
$ pkglocate libgnatcoll_postgres.so
- в пакетах и ситеме (в базе) такого не обнаружено
"любые разделяемые библиотеки из каталогов /usr/lib* на локальной системе жертвы"
- OpenBSD в /usr/lib/ держит исключительно системные/базовые библиотеки.. как уже замечено выше - эт не помойка.. в отличие от..
"Совершение атаки возможно только если пользователь подключился по ssh к системе, контролируемой злоумышленником, включив проброс сокета к ssh-agent по ssh при помощи опции "-A" или настройки ForwardAgent в файле конфигурации. Кроме того, для успешной атаки в системе жертвы должны присутствовать определённые библиотеки."
- считать ли это дырой в базовой инсталляции OpenBSD? скорее всего - нет, т.к. настройка ssh-agent целиком на совести пользователя.. предложение стартануть sshd инсталл опёнка выдаёт (вроде, если не путаю), но соглашаться или нет на старт (с дефолтными настройками) - также зависит от пользователя..
новость оч приятная, т.к. хоть кто-то делает аудит кода и выкладывает его результаты.. итог - практически мгновенный патч, закрывающий уязвимость..
в дополнение - дефолтные настройки ssh для OpenBSD:$ grep -iE "agent|forward" /etc/ssh/ssh_config
# ForwardAgent no
# ForwardX11 noи ман, что характерно, отдельно предупреждает любителей экспериментов:
$ man ssh_config
**
ForwardAgent
Specifies whether the connection to the authentication agent (if
any) will be forwarded to the remote machine. The argument may
be yes, no (the default), an explicit path to an agent socket or
the name of an environment variable (beginning with `$') in which
to find the path.Agent forwarding should be enabled with caution. Users with the
ability to bypass file permissions on the remote host (for the
agent's Unix-domain socket) can access the local agent through
the forwarded connection. An attacker cannot obtain key material
from the agent, however they can perform operations on the keys
that enable them to authenticate using the identities loaded into
the agent.думаю, что дефолт у многих аналогичен..
во Фре закрывать нечего))
# date
Fri Jul 21 10:46:40 MSK 2023
# freebsd-update fetch install
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
No updates needed to update system to 13.2-RELEASE-p1.
No updates are available to install.
>> во Фре закрывать нечего))гхм.. или кто-то не торопится закрывать найденную уязвимость..
> во Фре закрывать нечего))...
> No updates needed to update system to 13.2-RELEASE-p1.
> No updates are available to install.Это конечно офигительный способ проверки систем на уязвимости :)
> во Фре закрывать нечего))
> # date
> Fri Jul 21 10:46:40 MSK 2023commit d578a19e2cd312ef0ec842c9f16f97d66caea22a
Author: Ed Maste <emaste@FreeBSD.org>
Date: Wed Jul 19 13:02:33 2023 -0400
...
Fix CVE-2023-38408 - a condition where specific libaries loaded via
ssh-agent(1)'s PKCS#11 support
Стараюсь каждый раз указывать опцию
ssh -a ...
Не могу придумать, зачем мне сокет ssh-agent, тем более на компьютер злоумышленника.