Це взагалі не є ризиком для безпеки, оскільки ви завжди можете встановлювати лише змінні середовища для вашого поточного середовища (наприклад, поточний сеанс Bash) і, використовуючи exportкоманду, його дочірні середовища (сценарії, які ви запускаєте, підрозділи тощо). Неможливо ескалювати змінну середовища, створену або модифіковану в батьківське середовище. Це включає, що звичайним користувачам неможливо вносити загальносистемні зміни.
Тож єдине середовище, на яке вплине, якщо ви запустите, export LD_LIBRARY_PATH=...- це ваша поточна оболонка та будь-які її допоміжні оболонки, які ви могли б нереститися пізніше. Скажімо, ви змінюєте шлях пошуку на включення заражених бібліотек на початку, тобто з найвищим пріоритетом. Потім ви запускаєте виконуваний файл, який завантажує одну із заражених гілок, навіть не знаючи про це. Що відбувається зараз?
У вас є зловмисний код (із зараженої бібліотеки), який працює під власним обліковим записом користувача з регулярними правами не адміністратора. Це може здатися поганим, але насправді ... так що? Він працює з регулярними привілеями користувачів, що знову ж таки означає, що він не може впливати на всю систему. До речі, безпосередньо запустити виконуваний файл з тим же шкідливим кодом було б набагато простіше, ніж змінити шлях пошуку бібліотеки та чекати нормального виконуваного файлу для завантаження.
Висновок: звичайний користувач може змінювати лише свій власний шлях пошуку бібліотеки, а це означає, що вони також можуть завантажувати ті самі бібліотеки під свій звичайний обліковий запис користувача з регулярними привілеями, не загальносистемними. Однак це не має значення, чи змушують вони завантажувати заражену бібліотеку чи безпосередньо запускати заражений виконуваний файл. Ви б нічого не отримували, якби цю змінну оточення не змогли перекрити користувачі.
PS: Є також виконувані файли , які мають Setuid або setgid встановлений прапор, що означає , що вони не будуть працювати в якості користувача / групи, хто керує ними, але той , хто володіє ними. Наприклад, sudoвиконуваний файл належить корінь і має Setuid встановлений прапор, який означає , що він завжди працює як корінь при виконанні. З міркувань безпеки $LD_LIBRARY_PATHзмінна ігнорується виконуваними файлами з одним із встановлених / setgid- прапорів, встановлених для того, щоб переконатися, що звичайний користувач не може зробити виконувану програму з кореневими привілеями для завантаження довільних бібліотек.
(Дякую @Rinzwind, що вказав на це!)