Преамбула

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

Точно так же вы не заключаете переменную в кавычки, потому что в противном случае вы вносите уязвимости в системе безопасности. Вы цитируете переменные , потому что это неправильно (но если страх тюрьмы может помочь, почему бы и нет).

Небольшое резюме для тех, кто только что запрыгнул в поезд.

В большинстве оболочек, оставление раскрытия переменной без кавычек (хотя это (и остальная часть этого ответа) также применяется к подстановке команды ( `...` или $ (...) ) и арифметическое расширение ( $ ((...)) или $ [...] )) имеет очень особое значение .Лучше всего описать это как вызов некоторого неявного оператора split + glob .

cmd $var

на другом языке будет выглядеть примерно так:

cmd(glob(split($var)))

$ var сначала разбивается на список слов в соответствии со сложными правилами, включающими специальный параметр $ IFS ( часть split ) , а затем каждое слово, полученное в результате этого разделения, рассматривается как шаблон , который расширяется до списка файлов, соответствующих ему (часть glob ).

Например, если $ var содержит *. Txt, / var / *. Xml и $ IFS содержит ], , cmd будет вызываться с рядом аргументов, первый из них - cmd , а следующие - txt файлы в текущем каталоге и файлы xml в / var .

Если вы хотите вызвать cmd только с двумя буквальными аргументами cmd и *. Txt, / var / *. Xml , вы бы написали:

cmd "$var"

что было бы на другом вашем более знакомом языке:

cmd($var)

Что мы подразумеваем под уязвимостью в оболочке ?

В конце концов, это известно с незапамятных времен время, когда сценарии оболочки не должны использоваться в контекстах, чувствительных к безопасности. Конечно, хорошо, оставить переменную без кавычек - это ошибка, но она не может причинить столько вреда, не так ли?

Что ж, несмотря на то, что кто-нибудь скажет вам эту оболочку { {1}} скрипты никогда не должны использоваться для веб-CGI, или что, к счастью, в настоящее время большинство систем не позволяют использовать сценарии оболочки setuid / setgid, одна вещь, которая поражает оболочкой (удаленно эксплуатируемая ошибка bash { {1}}, который попал в заголовки в сентябре 2014 г.) показал, что оболочки по-прежнему широко используются там, где им, вероятно, не следует: в CGI, в сценариях подключения DHCP-клиента, в командах sudoers, вызывается командой (если не как ) командами setuid ...

Иногда неосознанно. Например, system ('cmd $ PATH_INFO') в php / perl / python скрипт CGI вызывает оболочку для интерпретации этой командной строки (не говоря уже о том, чтобы упомянуть тот факт, что cmd сам может быть сценарием оболочки, и его автор, возможно, никогда не ожидал, что он будет вызван из CGI).

У вас есть уязвимость, когда есть путь для повышения привилегий, то есть когда кто-то (назовем его злоумышленником ) может сделать то, что он не предназначено.

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

По сути, проблема возникает, когда ваш ошибочный код обрабатывает данные под контролем злоумышленника .

Теперь не всегда очевидно, откуда могут взяться эти данные , , и часто трудно сказать, сможет ли ваш код когда-либо обрабатывать ненадежные данные.

Что касается переменных. В случае сценария CGI, это совершенно очевидно, данные - это параметры CGI GET / POST и такие вещи, как файлы cookie, путь, хост. .. параметры.

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

Другой очень распространенный вектор - это имена файлов. Если вы получаете список файлов из каталога,возможно, файлы были помещены туда злоумышленником .

В этом отношении, даже при запросе интерактивной оболочки, вы можете быть уязвимы (при обработке файлов в / tmp или ~ / tmp {{ 1}}, например).

Даже ~ / .bashrc может быть уязвимым (например, bash интерпретирует его при вызове через ssh для запуска ForcedCommand как в git серверных развертываний с некоторыми переменными под управлением клиента ).

Теперь сценарий не может быть вызван напрямую для обработки ненадежных данных , но он может быть вызван другой командой, которая это делает. Или ваш неправильный код может быть скопирован в скрипты, которые это делают (вами через 3 года или одним из ваших коллег). Одно место, где это особенно критично , - это ответы на сайтах вопросов и ответов, поскольку вы никогда не узнаете, где могут оказаться копии вашего кода.

К делу; насколько это плохо?

Оставление переменной (или подстановки команды) без кавычек - это, безусловно, источник номер один уязвимостей безопасности, связанных с кодом оболочки. Отчасти потому, что эти ошибки часто приводят к уязвимостям , но также потому, что часто встречаются переменные без кавычек.

На самом деле, при поиске уязвимостей в коде оболочки первое, что нужно сделать, - это найти переменные без кавычек. Легко обнаружить, часто хороший кандидат, обычно легко отследить до данных, контролируемых злоумышленником.

Существует бесконечное количество способов, которыми переменная без кавычек может превратить в уязвимость. Я просто приведу здесь несколько общих тенденций.

Раскрытие информации

Большинство людей столкнутся с ошибками, связанными с переменными без кавычек из-за разделенной части (например, часто в файлах есть пробелы в их именах в настоящее время, а пробел находится в значении IFS по умолчанию). Многие люди упускают из виду часть glob . Часть glob по крайней мере так же опасна, как и разделенная часть .

Глобализация, выполняемая при необработанном внешнем вводе, означает злоумышленник может заставить вас прочитать содержимое любого каталога.

В:

echo You entered: $unsanitised_external_input

если $ unsanitised_external_input содержит / * , это означает, что злоумышленник может увидеть содержимое / . Ничего страшного. Это становится более интересным с помощью / home / * , который дает вам список имен пользователей на машине, / tmp / * , / home / * /. Forward для намеков на другие опасные действия, / etc / rc * / * для включенных служб ... Нет необходимости назвать их индивидуально. Значение / * / * / * / * / * / * ... просто перечислит всю файловую систему.

Уязвимости, связанные с отказом в обслуживании.

Если зайти слишком далеко в предыдущем случае, мы получили DoS-атаку.

Фактически, любая некотируемая переменная в контексте списка с неанитизированным входом является как минимум уязвимостью DoS.

Даже опытные разработчики сценариев оболочки обычно забывают цитировать такие вещи, как:

#! /bin/sh -
: ${QUERYSTRING=$1}

: - это команда, не выполняющая никаких действий.Что могло пойти не так?

Это означало присвоить $ 1 $ QUERYSTRING , если $ QUERYSTRING не задано. Это быстрый способ сделать сценарий CGI вызываемым из командной строки.

Этот $ QUERYSTRING все еще раскрывается, и поскольку он не цитируется, вызывается оператор split + glob .

Есть несколько глобусов, которые особенно дорого расширять . / * / * / * / * достаточно плох, так как он означает перечисление каталогов до 4 уровней ниже. Помимо активности диска и процессора , это означает сохранение десятков тысяч путей к файлам (40 КБ здесь на минимальной серверной ВМ, 10 КБ из которых - каталогов).

Теперь /*/*/*/*/../../../../*/*/*/* означает 40k x 10k и /*/*/*/*/../../../../*/*/*/*/../../../../*/*/*/* достаточно, чтобы поставить на колени даже самую мощную машину.

Попробуйте сами (хотя будьте готовы к тому, что ваша машина выйдет из строя или зависнет):

a='/*/*/*/*/../../../../*/*/*/*/../../../../*/*/*/*' sh -c ': ${a=foo}'

Конечно, если код:

echo $QUERYSTRING > /some/file

Тогда вы можете заполнить диск.

Просто выполните поиск в Google по оболочке cgi или bash cgi или ksh cgi , и вы найдете несколько страниц, на которых показано, как писать CGI в оболочках. Обратите внимание , насколько уязвима половина из тех, которые обрабатывают параметры.

Даже собственный файл Дэвида Корна уязвим (посмотрите на обработку файлов cookie).

вплоть до уязвимостей выполнения произвольного кода

Выполнение произвольного кода - наихудший тип уязвимости, поскольку, если злоумышленник может выполнить любую команду, нет ограничений на {{1} } что он может делать.

Обычно к ним приводит разделенная часть . Это разделение приводит к тому, что командам передается несколько аргументов, хотя ожидается только один. Хотя первый из них будет использоваться в ожидаемом контексте,другие будут в другом контексте , поэтому потенциально могут интерпретироваться по-разному. Лучше приведите пример:

awk -v foo=$external_input '$2 == foo'

Здесь целью было присвоить содержимое переменной оболочки $ external_input переменной foo awk .

Теперь:

$ external_input='x BEGIN{system("uname")}'
$ awk -v foo=$external_input '$2 == foo'
Linux

Второе слово, полученное в результате разделения $ external_input , не присваивается foo , но считается awk код (здесь выполняет произвольную команду: uname ).

Это особенно проблема для команд, которые могут выполнять другие команды ( awk , env , sed (один GNU), ] perl , find ...) особенно с вариантами GNU (которые принимают параметры после аргументов). Иногда вы не подозреваете, что команды может выполнять другие, например ksh , bash или zsh [ или printf ) ...

for file in *; do
  [ -f $file ] || continue
  something-that-would-be-dangerous-if-$file-were-a-directory
done

Если мы создадим каталог с именем x -o yes , тогда тест станет положительным, потому что это совершенно другое условное выражение , которое мы оцениваем .

Хуже того, если мы создадим файл с именем x -aa [0 $ (uname> & 2)] -gt 1 , по крайней мере со всеми реализациями ksh (включая sh большинства коммерческих Unix и некоторых BSD), который выполняет uname , потому что эти оболочки выполняют арифметические вычисления для операторов числового сравнения команда [.

$ touch x 'x -a a[0$(uname>&2)] -gt 1'
$ ksh -c 'for f in *; do [ -f $f ]; done'
Linux

То же самое с bash для имени файла, например x -a -v a [0 $ (uname> & 2)] .

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

С именами файлов можно делать все, что угодно.

$ touch -- '-R ..'
$ for file in *; do [ -f "$file" ] && chmod +w $file; done

И в итоге вы делаете .. записываемым (рекурсивно с помощью GNU chmod ).

Скрипты, выполняющие автоматическую обработку файлов в общедоступных областях, таких как / tmp , должны быть написаны очень осторожно.

А как насчет [$ # -gt 1]

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

Это как сказать. Эй, похоже, что $ # не может подчиняться оператору split + glob, давайте попросим оболочку разделить + glob его . Или Эй, давайте напишем неверный код только потому, что ошибка вряд ли будет обнаружена .

Насколько это маловероятно? Хорошо, $ # (или $! , $? или любая арифметическая подстановка) может содержать только цифры (или - для некоторых), поэтому часть glob отсутствует. Однако для того, чтобы часть split что-то делала , все, что нам нужно, это чтобы $ IFS содержал цифры (или - ).

В некоторых оболочках $ IFS может быть унаследован от среды, но если среда небезопасна, игра все равно окончена.

Теперь, если вы напишете такую ​​функцию, как:

my_function() {
  [ $# -eq 2 ] || return
  ...
}

Это означает, что поведение вашей функции зависит от контекста, в котором она вызывается. Или, другими словами, $ IFS становится одним из его входов. Строго говоря, когда вы пишете документацию по API для своей функции, она должна быть примерно такой:

# my_function
#   inputs:
#     $1: source directory
#     $2: destination directory
#   $IFS: used to split $#, expected not to contain digits...

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

Теперь, чтобы ошибка [$ # -eq 2] стала уязвимостью, вам нужно каким-то образом, чтобы значение $ IFS стало под контролем злоумышленника . Возможно, этого обычно не происходило бы , если бы злоумышленник не смог воспользоваться другой ошибкой.

Это не редкость. Распространенный случай - когда люди забывают очистить данные перед их использованием в арифметическом выражении . Мы уже видели выше, что он может разрешить выполнение произвольного кода в некоторых оболочках, но во всех из них он позволяет злоумышленнику присвоить любой переменной целочисленное значение. .

Например:

n=$(($1 + 1))
if [ $# -gt 2 ]; then
  echo >&2 "Too many arguments"
  exit 1
fi

И с $ 1 со значением (IFS = -1234567890) , эта арифметическая оценка имеет побочный эффект настроек IFS и следующая команда [ завершается ошибкой, что означает, что проверка на слишком большого количества аргументов пропущена.

Что делать, если оператор split + glob не вызывается?

Есть еще один случай, когда кавычки нужны вокруг переменных и других расширений: когда он используется в качестве шаблона.

[[ $a = $b ]]   # a `ksh` construct also supported by `bash`
case $a in ($b) ...; esac

не проверяет, совпадают ли $ a и $ b (кроме zsh )но если $ a соответствует шаблону в $ b . И вам нужно указать $ b , если вы хотите сравнивать как строки (то же самое в "$ {a # $ b}" или "$ {a% $ b}} " или " $ {a ## * $ b *} ", где $ b следует заключить в кавычки, если это не следует рассматривать как образец).

Это означает, что [[$ a = $ b]] может возвращать истину в тех случаях, когда $ a отличается от $ b (для например, когда $ a равно что-нибудь и $ b равно * ) или может возвращать false, когда они идентичны (например, когда оба $ a и $ b равны [a] ).

Может ли это привести к уязвимости системы безопасности? Да вроде любой баг. Здесь злоумышленник может изменить логический поток кода вашего скрипта и / или нарушить предположения, которые делает ваш скрипт. Например, с таким кодом:

if [[ $1 = $2 ]]; then
   echo >&2 '$1 and $2 cannot be the same or damage will incur'
   exit 1
fi

Злоумышленник может обойти проверку, передав '[a]' '[a]' .

Итак, если ни то сопоставление с образцом, ни оператор split + glob не применимы, в чем опасность оставить переменную без кавычек?

Я должен признать, что пишу:

a=$b
case $a in...

Там, цитирование не вредит, но не обязательно.

Однако одним из побочных эффектов опускания кавычек в этих случаях (например, в ответах на вопросы) является то, что это может послать неверное сообщение новичкам: что можно не заключать переменные в кавычки .

Например, они могут начать думать, что если a = $ b в порядке, то export a = $ b тоже будет (что не во многих shells в аргументах команды export в контексте списка) или env a = $ b .

А как насчет zsh ?

zsh исправил большинство этих неудобств дизайна. В zsh (по крайней мере, когда не в режиме эмуляции sh / ksh), если вы хотите разбиение , или подстановку , или сопоставление с образцом , вы должны запросить его явно: $ = var для разделения и $ ~ var для glob или для того, чтобы содержимое переменной обрабатывалось как шаблон.

Однако разделение (но не глобализация) все еще выполняется неявно при подстановке команд без кавычек (как в echo $ (cmd) ).

Кроме того, иногда нежелательным побочным эффектом отсутствия кавычек для переменной является удаление пустых . Поведение zsh аналогично тому, что вы можете достичь в других оболочках, полностью отключив подстановку (с помощью set -f ) и разделение (с помощью IFS = '' ) . Тем не менее, в:

cmd $var

Не будет split + glob , но если $ var пусто, вместо получения одного пустого аргумента cmd получит вообще никаких аргументов.

Это может вызвать ошибки (например, очевидный [-n $ var] ).Возможно, это может нарушить ожидания и предположения сценария и вызвать уязвимости, но я не могу сейчас привести не слишком надуманный пример).

Как насчет того, чтобы нужен оператор split + glob ?

Да, обычно вы хотите оставить переменную без кавычек. Но тогда вам нужно убедиться, что вы правильно настроили операторы split и glob , прежде чем использовать их. Если вам нужна только часть split , а не часть glob (что имеет место в большинстве случаев), то вам нужно отключить подстановку ( set -o noglob / set -f ) и исправьте $ IFS . В противном случае вы также вызовете уязвимости (например, пример CGI Дэвида Корна, упомянутый выше).

Заключение

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

Это одна из причин, почему это считается плохой практикой .

Спасибо, что дочитали до сих пор. Если это пролетит над вашей головой, не волнуйтесь. Нельзя ожидать, что все поймут все последствия написания кода так, как они его пишут. Вот почему у нас есть рекомендаций по передовой практике , поэтому им можно следовать, не обязательно понимая почему.

(и в случае, если это еще не очевидно, избегайте написания кода, чувствительного к безопасности, в оболочках).

И , пожалуйста, укажите свои переменные в ответах на этом сайте!

---

^{¹В ksh93 и pdksh и производных, раскрытие фигурных скобок также выполняется, если подстановка не отключена (в случае версий ksh93 вплоть до ksh93u +, даже если опция braceexpand отключена).}