1.1, Аноним (-), 20:59, 08/10/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> проблема устранена за счёт использования prctl() для блокирования доступа к /proc/self/{mem,maps}.
И это опенбсдшники, специалисты по секурити? Латающие дырки на суперклей?
| |
|
2.3, михаил (?), 21:26, 08/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
> И это опенбсдшники, специалисты по секурити? Латающие дырки на суперклей?
Главное оперативно и эффективно. Или вы считаете, что правильно конфиги пользователям настраивать тоже они должны ?
| |
|
3.6, Аноним (-), 21:41, 08/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Главное оперативно и эффективно.
Да, главное побольше всякого г-на насовать в openssh и потом удивляться что оперативно и эффективно приходится гасить дыры десятками, попутно в темпе вальса реинсталя системы с руткитами.
| |
|
|
5.15, Аноним (-), 01:57, 09/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Можно хоть тот же rsync over ssh. Он еще и докачку умеет, приколитесь?
| |
|
6.21, Аноним (-), 03:47, 10/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Как и ожидалось - ватнузятник даже не понял о чём тут :)
Но я добрый - один раз объясню. Так вот, если у тебя есть ssh шелл ... то вот конкретно эта тема тебе не интересна, малыш :)
| |
|
|
|
|
2.4, Xasd (ok), 21:31, 08/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
а в чём именно собственно дыра, если ты сам дал доступ до каталога /proc/ ?
это SSH , тут даже и залогиниваться в bash можно было бы.. (и сделать это без всякой возни с sftp)
| |
|
3.7, Аноним (-), 21:42, 08/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Дыра в том что эта дребедень позволяет сильно больше чем может ожидать администратор, и не сказать бы что это для такого софта хорошее качество.
| |
|
4.8, Xasd (ok), 21:48, 08/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
а что -- администратор может не знать что такое каталог /proc/ ? :-)
и да -- так как разработчики всё ещё НЕ убрали доступ для /proc/ -- то "дыра" (как ты её называешь) всё ещё остаётся, но всего лишь без одного частного случая её использования.
| |
4.18, Нанобот (ok), 10:03, 09/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Первопричина дыры - ожидания администратора, устранить первопричину невозможно. Вот и придумывают костыли
| |
|
3.9, anonymus (?), 22:21, 08/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
>а в чём именно собственно дыра, если ты сам дал доступ до каталога /proc/ ?
Вот скажите мне, почему все монтируют procfs в /proc и никто не пробовал в другое место? Вроде же никак гвоздями не прибито, а все дистрибутивы кладут его в одно и то же место.
| |
|
4.16, Аноним (-), 01:59, 09/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Вот скажите мне, почему все монтируют procfs в /proc и никто не
> пробовал в другое место? Вроде же никак гвоздями не прибито
Гвоздями может и не прибито, а софту ты это объяснять задолбаешься...
| |
|
|
2.13, Аноним (-), 00:07, 09/10/2014 [^] [^^] [^^^] [ответить]
| +3 +/– |
>> проблема устранена за счёт использования prctl() для блокирования доступа к /proc/self/{mem,maps}.
> И это опенбсдшники, специалисты по секурити? Латающие дырки на суперклей?
Если кто не понял:
1) В OpenBSD нет procfs (раньше была, но использовалась только для Linux ABI).
2) По умолчанию в OpenBSD для SFTP-сервера не используется internal-sftp. А уж что включают в дистрибутивах Linux и прочих ОС по дефолту - как повезёт.
3) Даже в случае выполнения кода, он будет выполнен от имени текущего пользователя, а не root... если, конечно, опять-таки, в вашем дистрибутиве эту защитную меру не отключили.
| |
|
3.14, Stax (ok), 00:59, 09/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> 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. А тут появляется возможность делать что угодно.
| |
|
|
1.17, Нанобот (ok), 10:00, 09/10/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
>проблема устранена за счёт использования prctl() для блокирования доступа к /proc/self/{mem,maps}.
костыль
| |
1.19, Аноним (-), 17:32, 09/10/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
>без выполнения chroot пользователь SFTP имеет доступ к некоторым частям базовой файловой системы
Ко всей фс с правами юзера же? host:../../ же =)
Сабжевую строку ни разу не видел в дефолтных конфигах дистров. А как узнать результирующий конфиг оненссш?
| |
|
2.22, Аноним (-), 03:50, 10/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> А как узнать результирующий конфиг оненссш?
Запусти без детача от консоли и с дебаг ключом, да и мучай пока не фффтыкнёшь :)
Но только этого как правило не достаточно, так - первый шаг.
| |
|
|