Вышел (http://www.openssh.com/txt/release-4.4) релиз OpenSSH 4.4 (http://www.openssh.com/).
В новой версии исправлена возможность DoS атаки (http://secunia.com/advisories/22091/) (чрезмерное потребление процессорных ресурсов), при использовании протокола SSH v.1. Также устранена возможность "race condition" в обработчике сигналов, которая может теоретически использована для удаленного запуска кода злоумышленника на стадии предшествующей аутентификации, при условии включения GSSAPI аутентификации. Код функций malloc и realloc заменен на реализацию с защитой от переполнения буфера.
Из новшеств можно отметить появление директивы "Match", через которую можно задавать условия использования других директив в зависимости от IP-адреса, имени или группы пользователя. Другая новая директива "ForceCommand" аналогична опции "command=" из ~/.ssh/authorized_keys, и позволяет совместно с директивой "Match" запускать внешние программы при входе определенных пользователей.
Кроме того в sftp-server расширены возможности ведения логов, добавлена экспериментальная поддержка SELinux, реализована функция использования аппаратных акселераторов для OpenSSL, исправлено около 30 разноплановых ошибок, сред которых утечка памяти и файловых дескрипторов.
URL: http://www.openssh.com/txt/release-4.4
Новость: http://www.opennet.me/opennews/art.shtml?num=8416
Куда-то делся замечательный сайт chrootssh.sf.net ;(
"исправлено около 30 разноплановых ошибок, сред которых утечка памяти и файловых дескрипторов" - на С без таких ужасных глюков писать невозможно или это руки кривые ? Файловые дескрипторы утекают прочь от помоичного кода. Как же всё криво в нашем мире.
На С большие проекты без утечек памяти писать практически невозможно. И это не столь страшно как думают громкоголосые товарищи. Утечки в апаче, например, лечатся периодическим рестартом процесса.
Рестарт процесса с потерей соединений. Немного лучше чем перезапуск Windows. Обалдеть. Я одного не понимаю: вместо того чтобы сказать "да, это так, но по-другому не научились" вы говорите "сам дурак, всё в порядке".
Между прочим, тоько в оооочень некоторых случаях апач держит соединение. А так - отфигарил ответ и закрыл. Так что главное, чтобы утечек небыло в главном модуле управления дочерними процессами. Да и сборщики мусора можно применить.
А ssh тоже запускать лучше через xinetd.
> Рестарт процесса с потерей соединений. Немного лучше чем перезапуск Windows. Обалдеть.Если бы Windows мог быть перезапущен незаметно для пользователя, то это было бы так.
Естественно подмена процесса происходит только после закрытия всех соединений.
Хотелось бы в догонку напомнить, что разработчики из OpenBSD знают свое дело на пятерку. Это вам не студенты-линуксоиды. Ошибки в их программных проектах самые обыденные, в любой более-менее приличной по объему программе без них ни как. Разница только в том, что баги в других проектах в основном вылавливают чужие специалисты, а в случае с OpenBSD - сами разработчики. За что большой им респект. Да и вообще, назвать таких людей, как Theo de Raadt или Dug Song криворукими, а код OpenSSH помоечным - это уже снобизм в стиле Киркорова и розовой кофточки, как мне кажется.