В списке рассылки Full Disclosure опубликован (http://seclists.org/fulldisclosure/2014/Oct/35) прототип эксплоита, поражающего 64-разрядные системы с OpenSSH 6.6 и более ранними выпусками, в которых используется неверная конфигурация SFTP-сервера. В частности, проблема проявляется, если в настройках указано принудительное выполнение встроенной реализации sftp ("ForceCommand internal-sftp"), но не определена директория для его изоляции в chroot (ChrootDirectory).Проблема связана с тем, что без выполнения chroot пользователь SFTP имеет доступ к некоторым частям базовой файловой системы, в том числе может обратиться к содержимому файла /proc/self/maps, через манипуляции с которым можно произвести запись в произвольную область памяти текущего процесса и организовать выполнение своего кода на сервере с правами непривилегированного пользователя. В представленном вчера выпуске OpenSSH 6.7 (http://www.opennet.me/opennews/art.shtml?num=40767) проблема устранена за счёт использования prctl() для блокирования доступа к /proc/self/{mem,maps}.
URL: http://seclists.org/fulldisclosure/2014/Oct/35
Новость: http://www.opennet.me/opennews/art.shtml?num=40781
> проблема устранена за счёт использования prctl() для блокирования доступа к /proc/self/{mem,maps}.И это опенбсдшники, специалисты по секурити? Латающие дырки на суперклей?
> И это опенбсдшники, специалисты по секурити? Латающие дырки на суперклей?Главное оперативно и эффективно. Или вы считаете, что правильно конфиги пользователям настраивать тоже они должны ?
> Главное оперативно и эффективно.Да, главное побольше всякого г-на насовать в openssh и потом удивляться что оперативно и эффективно приходится гасить дыры десятками, попутно в темпе вальса реинсталя системы с руткитами.
Начни с себя и переход и с sftp на xmodem
Можно хоть тот же rsync over ssh. Он еще и докачку умеет, приколитесь?
Как и ожидалось - ватнузятник даже не понял о чём тут :)
Но я добрый - один раз объясню. Так вот, если у тебя есть ssh шелл ... то вот конкретно эта тема тебе не интересна, малыш :)
а в чём именно собственно дыра, если ты сам дал доступ до каталога /proc/ ?это SSH , тут даже и залогиниваться в bash можно было бы.. (и сделать это без всякой возни с sftp)
Дыра в том что эта дребедень позволяет сильно больше чем может ожидать администратор, и не сказать бы что это для такого софта хорошее качество.
а что -- администратор может не знать что такое каталог /proc/ ? :-)и да -- так как разработчики всё ещё НЕ убрали доступ для /proc/ -- то "дыра" (как ты её называешь) всё ещё остаётся, но всего лишь без одного частного случая её использования.
Первопричина дыры - ожидания администратора, устранить первопричину невозможно. Вот и придумывают костыли
>а в чём именно собственно дыра, если ты сам дал доступ до каталога /proc/ ?Вот скажите мне, почему все монтируют procfs в /proc и никто не пробовал в другое место? Вроде же никак гвоздями не прибито, а все дистрибутивы кладут его в одно и то же место.
почему только proc? можно и dev положить в c:/system/drivers
Прибито, в огромном количестве софта.
> Вот скажите мне, почему все монтируют procfs в /proc и никто не
> пробовал в другое место? Вроде же никак гвоздями не прибитоГвоздями может и не прибито, а софту ты это объяснять задолбаешься...
в OpenBSD вообще нет никакой /proc
>> проблема устранена за счёт использования prctl() для блокирования доступа к /proc/self/{mem,maps}.
> И это опенбсдшники, специалисты по секурити? Латающие дырки на суперклей?Если кто не понял:
1) В OpenBSD нет procfs (раньше была, но использовалась только для Linux ABI).
2) По умолчанию в OpenBSD для SFTP-сервера не используется internal-sftp. А уж что включают в дистрибутивах Linux и прочих ОС по дефолту - как повезёт.
3) Даже в случае выполнения кода, он будет выполнен от имени текущего пользователя, а не root... если, конечно, опять-таки, в вашем дистрибутиве эту защитную меру не отключили.
> 2) По умолчанию в OpenBSD для SFTP-сервера не используется internal-sftp. А уж что включают в дистрибутивах Linux и прочих ОС по дефолту - как повезёт.По дефолту этого не может быть нигде, т.к. это не указание "используемого sftp-сервера", а ограничение конкретного пользователя, давая ему возможность использовать *только* sftp-сервер. Т.е. такую конфигурацию может поставить только админ. И обычно это делали вместе с chroot, но, видимо, не всегда.
А виной всему хаутшки вроде http://en.wikibooks.org/wiki/OpenSSH/Cookbook/SFTP - ими полон интернет. Вначале рассказывают про internal-sftp, а следующим рецептом "а еще можно это все в chroot"..., с комментариями типа "this may not be usable", "a compromise can be made" и т.д.
Т.е. тому, кто читает приходится включать голову, а не тупо копипастить. Подозреваю, по этой причине кто-то может останавливаться на предыдущем рецепте о форсировании sftp без chroot. Ну что поделаешь.> Даже в случае выполнения кода, он будет выполнен от имени текущего пользователя, а не root... если, конечно, опять-таки, в вашем дистрибутиве эту защитную меру не отключили.
А в этом и смысл дыры - опция не разрешает пользователям выполнять команды, а только пользоваться sftp. А тут появляется возможность делать что угодно.
>проблема устранена за счёт использования prctl() для блокирования доступа к /proc/self/{mem,maps}.костыль
>без выполнения chroot пользователь SFTP имеет доступ к некоторым частям базовой файловой системыКо всей фс с правами юзера же? host:../../ же =)
Сабжевую строку ни разу не видел в дефолтных конфигах дистров. А как узнать результирующий конфиг оненссш?
> А как узнать результирующий конфиг оненссш?Запусти без детача от консоли и с дебаг ключом, да и мучай пока не фффтыкнёшь :)
Но только этого как правило не достаточно, так - первый шаг.