Никогда не видел, чтобы хотя бы где-то правильно указывали, как использовать sudo. Ни-ко-гда. Во всех официальных инструкциях, в книгах, в статьях, на форумах — везде предлагают использовать sudo неправильно. И ни один из известных мне дистрибутивов GNU/Linux не препятствует этому.
Я не специалист по компьютерной безопасности, но я считаю это серьёзным просчётом, причём не спрятанным где-то далеко в хитровымудренной программной ошибке, а лежащим на поверхности всё то долгое время, как существует sudo.
В чём же проблема?
Дело в том, что применение sudo при указании только имени без полного пути даёт возможность злонамеренному коду, выполняющемуся от имени пользователя повысить привилегии и получить пароль пользователя.
Если злонамеренный код изменит переменную окружения PATH, добавив в её начало путь, где лежит исполнимый файл с именем sudo, или же воспользуется открытым для записи каталогом, уже находящимся в PATH для обеспечения дополнительной функциональности в пространстве пользователя, то при запуске по имени будет выполнен подложенный sudo, а не системный, со всеми вытекающими отсюда следствиями. Проверим:
Главная неприятность заключается в том, что если приглядеться, то можно увидеть, что уязвимость относится не только к sudo, но и к другим утилитам: для смены пользователя, смены прав и владельца файла, программам, выполняющим и создающим другие программы: командным и скриптовым интерпретаторам, компиляторам. Не забудем и динамическую загрузку библиотек вместе с LD_LIBRARY_PATH.
Не слишком ли много всего? Слишком, достаточно слишком, чтобы ничего не менять в привычном для большинства пользователей GNU/Linux раскладе дел. И находясь в положении неуловимого Джо, по прежнему высокомерно смотреть в сторону пользователей Windows, посмеиваться над производителями антивирусов, и искромётно шутить о том, где же найти инструкцию, чтобы запустить таки зловредную программу.
Ждём грома? Нет? Тогда вот, что следует сделать разработчикам дистрибутивов GNU/Linux в сотрудничестве с разработчиками используемых программ, в первую очередь командных интерпретаторов:
Я не специалист по компьютерной безопасности, но я считаю это серьёзным просчётом, причём не спрятанным где-то далеко в хитровымудренной программной ошибке, а лежащим на поверхности всё то долгое время, как существует sudo.
В чём же проблема?
Дело в том, что применение sudo при указании только имени без полного пути даёт возможность злонамеренному коду, выполняющемуся от имени пользователя повысить привилегии и получить пароль пользователя.
Если злонамеренный код изменит переменную окружения PATH, добавив в её начало путь, где лежит исполнимый файл с именем sudo, или же воспользуется открытым для записи каталогом, уже находящимся в PATH для обеспечения дополнительной функциональности в пространстве пользователя, то при запуске по имени будет выполнен подложенный sudo, а не системный, со всеми вытекающими отсюда следствиями. Проверим:
echo "echo мама, где я, куда я попал?" > sudo chmod +x sudo export PATH=.:$PATH sudoПравильное содержимое лже-sudo можете придумать сами.
Главная неприятность заключается в том, что если приглядеться, то можно увидеть, что уязвимость относится не только к sudo, но и к другим утилитам: для смены пользователя, смены прав и владельца файла, программам, выполняющим и создающим другие программы: командным и скриптовым интерпретаторам, компиляторам. Не забудем и динамическую загрузку библиотек вместе с LD_LIBRARY_PATH.
Не слишком ли много всего? Слишком, достаточно слишком, чтобы ничего не менять в привычном для большинства пользователей GNU/Linux раскладе дел. И находясь в положении неуловимого Джо, по прежнему высокомерно смотреть в сторону пользователей Windows, посмеиваться над производителями антивирусов, и искромётно шутить о том, где же найти инструкцию, чтобы запустить таки зловредную программу.
Ждём грома? Нет? Тогда вот, что следует сделать разработчикам дистрибутивов GNU/Linux в сотрудничестве с разработчиками используемых программ, в первую очередь командных интерпретаторов:
- Совершать поиск по PATH и LD_LIBRARY_PATH не по порядку, заданном в тексте переменной, а ставить в приоритете системные каталоги.
- Запретить менять переменные окружения PATH и LD_LIBRARY_PATH без административных прав.
- Запретить по умолчанию изменение LD_LIBRARY_PATH
- Убрать права на запись для пользователя на файлы, используемые в автозагрузке.
- Запретить запуск без подписи ряда программ, находящихся в зоне риска.
-
Запускать sudo только по полному пути. Если /usr/bin/sudo слишком длинно, то можно его перенести в корень
/usr/bin/sudo ln -s /usr/bin/sudo /
- Сменить пользователя файлов .bashrc и .profile на root и ограничить права на запись
/sudo chown root .bashrc .profile; /sudo 040 .bashrc .profile
Комментариев нет:
Отправить комментарий