В OpenSSH выявлена (http://seclists.org/oss-sec/2016/q4/185) уязвимость, которую можно использовать для инициирования отказа в обслуживании через исчерпание доступной памяти на сервере. Ошибка в коде обмена ключами позволяет любому внешнему атакующему (аутентификация не требуется) отправить серию специально оформленных запросов KEXINIT, каждый из которых приведёт к потреблению процессом до 384 Мб памяти. Например, отправив 10 одновременных запросов можно израсходовать 3.8 Гб памяти, а 100 - 38 Гб. Исправление пока доступно в виде патча (http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/kex...).URL: http://seclists.org/oss-sec/2016/q4/185
Новость: http://www.opennet.dev/opennews/art.shtml?num=45343
блин, только стаблюверсию 6.0 собрал и раскидал...а почему мини-новость? и где волнующие подробности?
Потому что сегодня уже во всех апдейтах будет фикс.
непонятно даже, каких версий касается - оригинальной, portable или всех. но, судя по тому, что прямо в дерево openbsd коммит вфигачили - умрём мы действительно все
пробил все зеркала - ничего нового. потом смотрю, а коммит-то от 10 октября, ещё с 13-й эрраты. у меня билды от 15 октярбя, так что можно спать спать спокойно :)
Тоже обнаружил, что уже неделю как исправлено.Кстати, в коммите речь идёт о 128 МБ, а обнаруживший утверждает, что 384 МБ, а в коммите описка. Причём ни та, ни другая сторона не объясняют, откуда числа.
и коммит, и это письмо в рассылку от одного и того же человека, так что это одна и та же сторона.я конечно не расист, но он слегка китаец. возможно это обьясняет скупость предоставленной информации.
> и коммит, и это письмо в рассылку от одного и того же человека, так что это одна и та же сторона.Я предположил о двух разных людях исходя из имени (и адреса email) автора коммита и имени вот того китайца 石磊 <shilei-c () 360 cn>:
Author: markus@openbsd.org <markus@openbsd.org> 2016-10-10 21:28:48
> -/* $OpenBSD: kex.c,v 1.126 2016/09/28 21:44:52 djm Exp $ */
> +/* $OpenBSD: kex.c,v 1.127 2016/10/10 19:28:48 markus Exp $ */Разве что Markus может оказаться его псевдонимом на западный лад. Но тогда он говорил бы о себе же в третьем лице:
> Reported by shilei-c at 360.cn
Что исключено, так как он - автор коммита.
A, прошу прощения, проглядел автора коммита.таки да, два человека.
> Потому что сегодня уже во всех апдейтах будет фикс.вот эта 13-я эррата
https://ftp.openbsd.org/pub/OpenBSD/patches/6.0/common/013_s...
сколько у тебя серверов, что ты компиляешь?
ээээ, переведи. каких ещё серверов? стаблеверсию можно получить только из сырцовman release
Это буратино и его полтора локалхоста.
Что то не понял я, а где сам фикс для OpenSSL то? Все ссылки на openbsd
Ты путаешь OpenSSL и OpenSSH. Это две разные хреновины, у них разные авторы.
потому что openssh - это часть проекта openbsd и разрабатывается в основной ветке openbsd
Непогрешимый и защищенный openbsd. Не, не слышал.
и чё, много поломали? в OpenBSD эта проблема уже 9 дней, как исправлена
> и чё, много поломали? в OpenBSD эта проблема уже 9 дней, как исправленаБыстро поднятый маздай - упавшим не считается?
А эксплойт где то есть рабочий? Не зла ради, хотел бы посмотреть на виртуалке хотя бы.
доооооооооооооооооооооо
Сказал бы лучше, что, мол, друг тут интересуется
Он, наверное, совсем тривиальный. Похоже, одно из первых действий после подсоединения клиента - это сервер посылает версию протокола. И сразу же идёт отсылка SSH2_MSG_KEXINIT. Ещё до выбора протокола шифрования.
> А эксплойт где то есть рабочий? Не зла ради, хотел бы посмотреть
> на виртуалке хотя бы.Зачем тебе дубинка, обезьянка? Бери уж термоядерную гранату сразу - https://github.com/jgamblin/Mirai-Source-Code.git
Только это, развязывание термоядерной войны - международное преступление, есличо.
OpenSSH upstream dos not consider this as a security issue btw.It seems the only thing the attacker could do here, is self-dos his own
connection. Regarding consuming memory on the server, by opening several
concurrent connections at the same time, there are various protections
available in opensshd_config file, such as "MaxStartups", which can
limit the maximum number of sessions per network connections.This value is effectively set to 10:30:100 so maximum of 100 * 128 MB
can be allocated, which is pretty much for unauthenticated user. Though
the rate limiting starts to drop connection after 10, which is like 1GB
and which should not hurt the server (though it is not cool).