Чому здатність визначати функції в змінній навколишнього середовища не є ризиком безпеки сама по собі?

Як я це розумію, загалом вважається безпечним дозволити будь-кому надавати інформацію, яка буде зберігатися в змінній навколишнього середовища. Уразливість оболонки тут є проблемою, оскільки це означає, що код в кінці визначення функції всередині змінної середовища буде виконуватися, коли запускається новий екземпляр bash, і ви, очевидно, не хочете, щоб хтось запускав будь-який код, який, будь ласка, на вашому сервері . Самі визначення функцій, мабуть, не є ризиком безпеки та дозволяються, оскільки їх потрібно чітко вимагати для виконання коду.

Моє запитання: чому не може зловмисний користувач просто визначити функцію, що містить їх шкідливий код як загальну команду, як, lsа потім сподіватися, що сценарій (або що завгодно запущений) буде використовувати цю команду в якийсь момент?

Приклад того, що я маю на увазі:

$ export ls='() { echo "doing bad things..."; }'
$ bash -c ls
doing bad things...

Це ризик для безпеки. Це взагалі, чому ви не можете зробити це під час переходу в інший контекст (віддалене управління системою, зміна користувачів тощо).

Якщо у вас є можливість створити будь-яку змінну середовища, яку ви хочете, існує будь-яка кількість потенційних способів виконання довільного коду.
Візьмемо $LD_PRELOADяк приклад. Якщо у вас є можливість встановити цю змінну, ви можете замінити функції бібліотеки та вставити там свій код. Ви можете встановити $DISPLAYзмінну та переспрямувати X-дисплей, до якого підключається програма, щоб ви могли контролювати додаток.

Ось чому такі речі, як sudoпозбавлення середовища всіх змінних. sudoдозволяє лише декілька вибраних змінних. І з цих змінних, вони дезінфікують їх (він проходить через $TERMзмінну, але не буде, якщо вона містить незвичні символи).

Я б сказав, що це, коли bash - це ваш / bin / sh. Це не особливість оболонки Bourne, і я б обміную, що це не особливість оболонки posix, адже вони, можливо, хочуть прямо заборонити це.

Незважаючи на свою назву, Bash - це більше шкаралупа похідної кукурудзи, ніж оболонка бурна, і єдина шкаралупа, схожа на Korn, яка має цю особливість, і на мою думку, це особливість кухонного мислення, яка не має практичних чеснот. Розробники, які уникають функцій bash для стандартів, таких як оболонка Bourne, оболонка posix або підмножина ksh88, які мають спільні сучасні оболонки, або іншими словами, прихильнилися до передового досвіду та стандартних ідіом, шоковані, коли їх програмне забезпечення ввімкнено Linux та mac зараз потенційно вразливі, оскільки автори експлуатації можуть вільно використовувати "башизми", незважаючи на їхні наміри. Що стосується покращеної сумісності, коли викликається як / bin / sh над іншими похідними оболонки кукурудзи, це лише якщо / bin / sh - ваша оболонка для входу, або інтерактивна оболонка, коли bash поводиться більше як оболонка bourne, ніж оболонка korn,

Я спробую переконати вас, що це функція кухонної мийки з двома випадками: ви вбудований розробник, який робить такі пристрої, як маршрутизатори, приєднаний до мережі-накопичувач 1-й більший env, означає більше, пам’ять, так, більше витрат, так менше прибутків, тому, якщо це було приводом для розгляду використання цієї функції bash, чи не слід замість цього використовувати FPATH та автозавантажувати, ksh88 функції замість цього? замість того, щоб передавати цілий байт функції для байта в оточенні? Ви навіть можете розглянути синтаксичний аналіз та обрізання навколишнього середовища, перш ніж він потрапить до оболонки оболонки, яка могла б неправильно змінити змінну, як-от просто відфільтрувати ^ $ (. *) $ Тощо).

Це підкреслює те, що є унікальним у цьому, не має значення, що це за змінна, і сценарій не повинен посилатися або використовувати змінну, він все ще може бути вразливим.

#!/bin/sh
exec /usr/local/myapp/support/someperlscript.pl

Навіть все, що знаходиться під сонцем, вищезазначене має бути настільки ж безпечним, як і сценарій perl, ви не використовуєте жодних змінних, як би ви могли розібратись? Зміна на

#!/bin/bash -norc
exec /usr/local/myapp/support/someperlscript.pl

Не допомагає і це, це не мало нічого спільного з ENV або чим-небудь подібним - всі згоряють, тому що баш повинен бути унікальним. Те, що в bash версії 2 є проблемою, для мене доводить, що ніхто ніколи не використовує цю функцію для своїх застосувань, бо в іншому випадку вона не повинна була ховатися довкола цього часу. І що ще гірше, в основному немає уникнути цієї функції . Ось приклад із записом "su -", який, якщо ви когось запитаєте, поясненням буде, що це відкидає середовище, перевірте сторінку людини, і ви знайдете лише 99,9%. Я перевірив це правильно, оскільки в цій системі / bin / sh є оболонка входу кореня, а / bin / sh - bash, Але в цьому прикладі я намагаюсящоб затвердіти .bash_profile. Я перейменував свій існуючий на root (який увімкнено), але я міркував, якщо su, то можливо sudo, у будь-якому разі я змінив це:

exec env -i TERM=vt102 LOGNAME=root USER=root HOME=/var/root /bin/ksh -i

Отже, я фактично кидаю навколишнє середовище повністю і використовую мінімальну середовище, а потім запускаю оболонку, яка не повинна мати проблеми, замість поточного процесу. Потім замість стандартного прикладу спробуйте:

%dock='() { echo -e "\e[2t\c"; echo dockshock;} ; dock' su 

Це ілюструє, як це не має нічого спільного з розбором будь-якої конкретної функції, і експлойт може посилатися на функцію та використовувати її. Ви можете уявити, що функція має логіку для перевірки наявності кореня і т.д. дивись докшок - але, і що? Тепер спробуйте це:

%TERM='() { echo -e "\e[2t\c"; echo dockshock;} ; TERM' su - 

І відгадайте, що? Вікно засмоктується на лаву підсудних. Ось як це виглядає згодом ..

%TERM='() { echo -e "\e[2t\c"; echo dockshock;} ; TERM' su -
Password:
dockshock
# env
_=/usr/bin/env
HOME=/var/root
LOGNAME=root
TERM=vt102
USER=root
# echo $0
/bin/ksh
#

Так, значить, для цього! Експортовані функції насправді мають пріоритет над rc-скриптами. Ви не можете ухилитися від цього.