LINUX.ORG.RU
Форум — Talks  

LD_LIBRARY_PATH over ssh

 , , nologin,


0

2

Заметил, что программа /usr/sbin/nologin в фрибсд занимает 600кб. Всё, что она делает это отправка в syslog сообщения «attempted to login as %s on %s» (имя юзера и имя tty), отправка «This account is currently not available.» в stdout и выход с кодом 1 (неуспех).

Оказалось, такой размер у неё из-за статической линковки, а её необходимость объясняется так:

# It is important that nologin be statically linked for security
# reasons.  A dynamic non-setuid binary can be linked against a trojan
# libc by setting LD_LIBRARY_PATH appropriately.  Both sshd(8) and
# login(1) make it possible to log in with an unsanitized environment,
# rendering a dynamic nologin binary virtually useless.

Ну, sshd можно настроить чтобы он принимал LD_LIBRARY_PATH от клиента, но это никак не дефолт и если кто-то это сделал то он наверно специально хотел сделать дыру и незачем ему мешать. Или есть какие-то другие соображения?

★★★★★

Ты наркоман?

Чтобы LD_LIBRARY_PATH сработало, надо вначале подсунуть на хост свою libc. А если у тебя есть возможность что-то подсунуть, зачем тебе лезть под юзером с nologin вместо шелла?

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

Во-первых, при чём тут я? Это объяснение из Makefile nologin-а, я и интересуюсь его логикой.

Во-вторых, сценарий подсовывания как раз примерно понятен - на сервере вполне может быть какая-либо вариация ftp или даже аплоад файлов через веб (надо только чтобы имя файла можно было выбрать и знать абсолютный путь куда они складываются).

firkax ★★★★★
() автор топика
Ответ на: комментарий от mord0d

Подсунуть не обязательно libc, а /tmp/libinjected.so, которая в инициализаиторе уже что-то плохое сделает.

А если у тебя есть возможность что-то подсунуть, зачем тебе лезть под юзером с nologin вместо шелла?

например у этого юзера с nologin есть какие-то специфические права (на определённые файлы/псевджовайлы), которых нет у того кто подкладывал в /tmp.

По теме - кажется что дырка не в sshd, а в идее ограничивать право логина таким странным костылём, как «запускать код дадим, но только тот который что-то печатает и сразу выходит». А потом этот вывод используют или как side-channel атаку, или как DoS методом «первый байт ответа приняли, а дальше пока не можем»

GPFault ★★★★
()
Последнее исправление: GPFault (всего исправлений: 2)
Ответ на: комментарий от GPFault

кажется что дырка не в sshd

Так нету же дырки, это надо специально конфиг править чтобы разрешить такие (и вообще хоть какие-то) переменные.

Касательно «костыля» - git over ssh по такому же принципу права ограничивает (чтобы у гит-клиента шелл-доступ не появился). Но с другой стороны там у залогиненого юзера полезная передача данных потом происходит, а тут нет.

firkax ★★★★★
() автор топика

Или есть какие-то другие соображения?

/usr/sbin/nologin отрабатывает как логин-шелл в сценарии, когда пользователь уже прошёл авторизацию. Смысл программы в том, чтобы завершить сеанс. Загрузка через LD_LIBRARY_PATH произвольного кода позволяет поменять логику /usr/sbin/nologin на произвольную, делая саму программу бессмысленной.

LamerOk ★★★★★
()
Вы не можете добавлять комментарии в эту тему: только для зарегистрированных, score>=50.