Является ли «LD_LIBRARY_PATH» угрозой безопасности?

8

Нам известен ld.soпоиск библиотек в каталогах, указанных в переменной среды $LD_LIBRARY_PATH, но обычные пользователи могут запускать:

export LD_LIBRARY_PATH=dir1:dir2...

Они могут сохранить зараженную библиотеку по пути с более высоким приоритетом, чем исходный, чтобы ld.soнайти ее вместо доверенной библиотеки в ld.so.cache.

Это риск?
Как мы можем отключить запись в эту переменную среды для обычного пользователя?

Sinoosh
источник
Спасибо @Byte Commander за редактирование. мой английский не очень хорош :)
Sinoosh
Нет проблем, это лучше, чем в среднем :)
Byte Commander

Ответы:

17

Это вовсе не угроза безопасности, потому что вы всегда можете установить только переменные среды для вашей текущей среды (например, текущего сеанса Bash) и, используя exportкоманду, ее дочерние среды (запускаемые вами сценарии, подоболочки и т. Д.). Невозможно преобразовать переменную среды, созданную или измененную в родительскую среду. Это включает в себя то, что обычные пользователи не могут вносить общесистемные изменения, конечно.

Таким образом, единственное окружение, которое будет затронуто, если вы запустите, export LD_LIBRARY_PATH=...это ваша текущая оболочка и любые ее подоболочки, которые вы можете создать позже. Допустим, вы изменили путь поиска для включения зараженных библиотек в начале, то есть с наивысшим приоритетом. Затем вы запускаете исполняемый файл, который загружает одну из зараженных библиотек, даже не подозревая об этом. Что происходит?

У вас есть вредоносный код (из зараженной библиотеки), работающий под вашей учетной записью с обычными правами администратора. Это может звучать плохо, но на самом деле ... ну и что? Он работает с правами обычного пользователя, что опять же означает, что он не может влиять на всю систему. Кстати, прямой запуск исполняемого файла с тем же вредоносным кодом был бы намного проще, чем изменение пути поиска в библиотеке и ожидание загрузки обычного исполняемого файла.

Заключение. Обычный пользователь может изменять только свой собственный путь поиска в библиотеке, что означает, что он может также загружать эти библиотеки только под своей учетной записью обычного пользователя с обычными несистемными привилегиями. При этом не имеет значения, принудительно ли они загружают зараженную библиотеку или запускают зараженный исполняемый файл напрямую. Вы бы ничего не получили, если бы эта переменная окружения не могла быть переопределена пользователями.

PS: Существуют также исполняемые файлы с установленным флагом setuid или setgid , что означает, что они будут работать не как пользователь / группа того, кто их запускает, а как того, кто им владеет . Например, sudoисполняемый файл принадлежит root и имеет установленный флаг setuid , что означает, что он всегда запускается как root при выполнении. По соображениям безопасности $LD_LIBRARY_PATHпеременная игнорируется исполняемыми файлами, для которых установлен один из флагов setuid / setgid, чтобы гарантировать, что обычный пользователь не сможет создать исполняемый файл с привилегиями root для загрузки произвольных библиотек.
(Спасибо @Rinzwind за это!)

Byte Commander
источник
Большое спасибо ! Я читаю книгу, в которой говорится, что «LD_LIBRARY_PATH считается угрозой безопасности, поскольку он может позволить несанкционированным программам случайно получить доступ к системным библиотекам или иным образом открыть пути к системным библиотекам для неавторизованных пользователей». что значит?
Sinoosh
1
@Sinoosh Я не могу придумать причину, почему это должно быть проблемой безопасности, если ненадежное приложение знает расположение моих системных библиотек. Если все настроено правильно, и вы не перепутали разрешения, они должны принадлежать пользователю root и не быть доступными для записи кем-либо еще, что означает, что нет никакого риска, что они будут заражены или изменены каким-либо образом (если вы не запустите ненадежное приложение от имени root , но ты не сделаешь этого, верно?)
Byte Commander
1
@Sinoosh, см. Xahlee.info/UnixResource_dir/_/ldpath.html
Rinzwind,
@ Byte Commander, я согласен с тобой, а не с автором :)
Sinoosh
Этот ответ не совсем правильный. LD_LIBRARY_PATHКонечно, это проблема безопасности, когда вы загружаете вредоносную библиотеку и изменяете поведение двоичного файла.
Heemayl