Почему способность определять функции в переменной окружающей среды не является угрозой безопасности сама по себе?

Насколько я понимаю, в целом считается безопасным предоставлять кому-либо информацию, которая будет храниться в переменной окружения. Уязвимость shellshock является проблемой здесь, потому что это означает, что код в конце определения функции внутри переменной окружения будет выполняться при запуске нового экземпляра bash, и вы, очевидно, не хотите, чтобы кто-либо запускал какой-либо код, который им нравится на вашем сервере , Определения функций сами по себе, по-видимому, не являются угрозой безопасности, хотя и разрешены, потому что они должны быть явно вызваны для их выполнения кода.

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

  • Лучший инструмент для мониторинга использования сервера
  • Манипулировать имя файла с помощью команды find
  • присоединиться к sed output
  • Исходный доступ SELinux к другим сайтам с ограничениями
  • Используйте #! / Bin / sh или #! / Bin / bash для совместимости с Ubuntu-OSX и простоты использования и POSIX
  • Почему переменные PATH отличаются при запуске через sudo и su?
  • Пример того, что я имею в виду:

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

  • Bash: #: команда не найдена
  • Bash: Каково использование типа (встроенные Bash)?
  • Восстановить выполнение по умолчанию
  • Сценарий Bash ждет процессов и получает код возврата
  • Как преобразовать параметры inputrc в bashrc?
  • Каков канонический способ реализовать независимые от заказа параметры в сценариях bash?
  • 2 Solutions collect form web for “Почему способность определять функции в переменной окружающей среды не является угрозой безопасности сама по себе?”

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

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

    Вот почему такие вещи, как sudo разделяют среду всех переменных. sudo разрешает только несколько переменных. И из этих переменных она дезинфицирует их (она проходит через переменную $TERM , но она не будет, если она содержит необычные символы).

    Я бы сказал, что это, когда bash – ваш / bin / sh. Это не особенность оболочки bourne, и я бы поспорил, что это тоже не особенность оболочки posix, на самом деле они могут явно запретить ее.

    Баш действительно больше из корневой производной оболочки, чем раковина борна, несмотря на свое название, и ее единственная оболочка, похожая на Korn, которая имеет эту функцию, и, на мой взгляд, это функция кухни, которая не имеет практических достоинств. Разработчики, которые избегают возможностей bash для стандартов, таких как оболочка bourne, оболочка posix или подмножество ksh88, которые имеют современные оболочки, или, другими словами, привержены передовым методам и стандартным идиомам, шокированы, когда их программное обеспечение находится на linux и mac и теперь потенциально уязвимы, поскольку авторы эксплойтов могут свободно использовать «базисы», несмотря на их намерения. Поскольку улучшенная совместимость, когда вызывается как / bin / sh, по сравнению с другими производными оболочки korn, это только если / bin / sh является вашей оболочкой входа или интерактивной оболочкой, когда bash ведет себя скорее как оболочка bourne, чем оболочка korn, но когда вы используете скрипты, вы можете делать все, что может сделать bash, и никогда не жалуется или не предупреждает вас, что вы используете функции, которые действительно являются функциями оболочки korn или уникальны для bash.

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

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

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

    Для чего-либо еще под солнцем вышеупомянутое должно быть безопасным, как perl-скрипт, вы не используете какие-либо переменные, как вы могли бы неправильно их игнорировать? Переход на

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

    Не помогает, это не имело ничего общего с ENV или что-то в этом роде – каждый загорается, потому что bash должен быть уникальным. Тот факт, что у bash версии 2 есть проблема, мне доказывает, что никто никогда не использует эту функцию для своих приложений, потому что иначе она не должна была скрываться в течение этого долгого времени. И что еще хуже, в принципе не избежать этой функции . Вот пример с: «su», который, если вы спросите кого-нибудь, объяснит, будет ли он отбрасывать окружающую среду, проверьте страницу руководства, и вы найдете всего 99,9%. Я проверил этот правильный путь, так как на этой системе / bin / sh находится корневая папка root, а / bin / sh – bash, но в этом примере я пытаюсь затвердеть мой .bash_profile. Я переименовал свой существующий для root (который включен), но я думал, что если su, то, возможно, sudo, во всяком случае, я изменил это:

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

    Итак, я фактически полностью отбрасываю среду и использую минимальное env, а затем запускаю оболочку, которая не должна иметь проблемы, вместо текущего процесса. Затем вместо стандартного примера попробуйте:

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

    Это иллюстрирует, как это не имеет никакого отношения к разбору какой-либо конкретной функции, и эксплойт может ссылаться и использовать эту функцию. Вы можете представить, что функция имеет логику для проверки, если root и т. Д. В этом случае это всего лишь модифицированная форма, функция для обозначения или стыковки окна терминала, с использованием escape-последовательности, которая довольно стандартная, поэтому после того, как я нажму для подтверждения, я см. докшток – но, ну и что? Теперь попробуйте следующее:

     %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-скриптами. Вы не можете уклониться от него.

    Linux и Unix - лучшая ОС в мире.