S3.Blog

Как избежать передачи пользовательских переменных оболочке ОС при вызове exec() и system()?

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

$date = `/bin/date`;

Вы можете открывать "туннель" (pipe) к программе:

open (SORT, " | /usr/bin/sort | /usr/bin/uniq");

Вы можете запускать внешние программы и ждать окончания их выполнения через system():

system "/usr/bin/sort < foo.in";

или вы можете запускать внешние программы без возврата управления с помощью exec():

exec "/usr/bin/sort < foo.in";

Все эти выражения являются опасными если используют данные, введенные пользователем, которые могут содержать метасимволы. Для system() и exec() существует синтаксическая возможность, позволяющая запускать внешние программы напрямую, без обращения к оболочке ОС. Если вы передаете внешней программе аргументы, представляющие собой не строку, а список, то Perl не будет использовать оболочку, и метасимволы не вызовут нежелательных побочных эффектов. Например:

system "/usr/bin/sort","foo.in";

Вы можете использовать эту особенность для того, чтобы открыть туннель, не обращаясь к оболочке ОС. Вызывая open в магической последовательности символов |-, вы запускаете копию Perl и открываете туннель (pipe) к этой копии. Дочерняя копия Perl затем немедленно запускае внешнюю программу, используя список аргументов для exec().

open (SORT,"|-") || exec "/usr/bin/sort",$uservariable;
while $line (@lines) {
    print SORT $line,"\n";
}
close SORT;

Для чтения из туннеля без обращения к оболочке можно использовать похожий способ, с последовательностью -|:

open(GREP,"-|") || exec "/usr/bin/grep",$userpattern,$filename;
while (<GREP>) {
    print "match: $_";
}
close GREP;

Это те формы open(), которые необходимо всегда использовать в случаях, когда в другой ситуации вы использовали бы перенаправление open (piped open).

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

Вот синтакс:

system $настоящее_имя "ложное_имя","аргумент1","аргумент2"

Например:

$shell = "/bin/sh"

system $shell "-sh","-norc"

Этот пример запускает sh - оболочку операционной системы - с именем "-sh", заставляющим ее действовать интерактивно. Заметте, что настоящее имя программы должно храниться в виде переменной, и что между именем переменной и началом списка аргументов нет запятой.

Можно записать эту команду более компактно:

system { "/bin/sh" } "-sh","-norc"

Что такое "проверки заразности" (taint checks) в Perl? Как их включить?

Как мы видели, одна из наиболее часто встречающихся проблем с безопасностью при программировании CGI - передача оболочке ОС пользовательских переменных без их проверки. Perl предлагает механизм проверки "заразности", который не позволяет этого делать. Любая переменная, которая проинициирована данными за пределами программы (включая данные из среды, стандартного ввода и командной строки) рассматривается как "заразная", и не может быть более использована за пределами программы. Зараза может распространяться. Если вы используете зараженную переменную для присвоения значения другой переменной, вторая переменная также оказывается заражена. Зараженные переменные не могут быть использованы для вызова eval(), system(), exec() или piped open(). Если вы попытаетесь это сделать, Perl прекращает работу и выводит предупреждение. Perl также откажется работать, если вы попытаетесь вызвать внешнюю программу, не установив явно значение переменной PATH.

В версии 4 языка Perl проверка включается при использовании специальной версии интерпретатора, называющейся "taintperl":

#!/usr/local/bin/taintperl

В версии 5 - используйте флаг -T при запуске интерпретатора:

 #!/usr/local/bin/perl -T

Ниже описано как "обеззараживать" (untaint) переменные.

Для более полного обсуждения вопроса можно обратиться к CGI/Perl Taint Mode FAQ (автор - Gunther Birzniek).

OK, я включил проверку заразности, как вы рекомендовали. Теперь мой скрипт прекращает работу с сообщением "Insecure $ENV{PATH} at line XX" при каждом запуске!

Даже если вы не доверяете переменной PATH при запуске внешних программ, существует возможность того, что это делает внешняя программа. Поэтому следует всегда включать такую строку в начале вашего скрипта, если вы используете taint checks:

 $ENV{'PATH'} = '/bin:/usr/bin:/usr/local/bin';

Отредактируйте ее так, чтобы перечислить директории, в которых вы хотите искать. Мысль о вклюяении текущего директория (".") в состав переменной PATH является плохой идеей.

Как "обеззаразить" (untaint) переменную?

После того, как переменная заражена, Perl не даст вам возможности использовать ее в функциях system(), exec(), piped open, eval(), обратных кавычках, или любой функции, которая влияет на что-либо за пределами программы (например - unlink). Вы не можете этого сделать даже если вы проверили переменную на содержание метасимволов или использовали команду tr/// или s/// для удаления метасимволов. Единственный способ обеззаразить переменную - использовать операцию поиска по маске и извлечение совпадающей подстроки. Например, если переменная должна содержать адрес электронной почты, то извлечь обеззараженную копию адреса можно следующим образом:

$mail_address=~/(\w[\w-.]*)\@([\w-.]+)/;
$untainted_address = "$1\@$2";

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

Я удаляю метасимволы из переменной, но Perl продолжает думать, что она заражена!

Смотри выше ответ на этот вопрос. Единственный способ обеззаразить переменную - применить поиск по маске.

Действительно ли небезопасна операция поиска $foo=~/$user_variable/?

Часто задача скрипта CGI на Perl состоит в получении от пользователя списка ключевых слов и использования их в операциях поиска по маске для нахождения совпадающих имен файлов (или чего - нибудь в этом роде). Само по себе это не опасно. Опасна оптимизация, которую некоторые программы Perl используют для ускорения поиска. При использовании переменной в операции поиска, выражение компилируется всякий раз при выполнении операции. Для избежания перекомпилирования, занимающего время, можно использовать специальный флаг - o, что приведет к тому, что выражение будет откомпилировано только однажды:

foreach (@files) {
    m/$user_pattern/o;
}

Теперь, однако, Perl будет игнорировать любые изменения в переменной, что приведет к неправильной работе циклов такого рода:

foreach $user_pattern (@user_patterns) {
    foreach (@files) {
        print if m/$user_pattern/o;
    }
}

Для обхода этой проблемы программисты, пишущие на Perl, часто используют такой трюк:

foreach $user_pattern (@user_patterns) {
    eval "foreach (\@files) { print if m/$user_pattern/o; }";
}

Проблема здесь состоит в том, что в операторе eval() используется пользовательская переменная. Если переменная не подвергается тщательной проверке, то можно заставить eval() выполнить произвольный код на Perl. Для понимания того, чем это грозит, подумайте, что произойдет в случае, если переменная будет иметь следующее значение: "/; system 'rm *'; /"

Проверки заразности (см. выше) позволяют поймать потенциальную опасность в этой области. Вы можете выбирать между отказом от такого рода оптимизации, или тщательным обеззараживанием переменной перед использованием. Полезная возможность в Perl5 состоит в использовании \Q и \E для комментирования метасимволов так, чтобы они не были использованы:

print if m/\Q$user_pattern\E/o;

Мой скрипт CGI требует большие привелегии, чем он получает как пользователь nobody. Как мне изменить идентификатор пользователя?

Прежде всего, действительно ли это необходимо? Предоставление больших прав увеличивает риск и позволяет взломанному скрипту нанести больше вреда. Если вы хотите предоставить скрипту права пользователя root, то сперва ОЧЕНЬ хорошо подумайте.

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

chmod u+s foo.pl

Вы можете предоставить ему права группы, к которой принадлежит владелец, установив бит s в поле группы:

chmod g+s foo.pl

Однако, многие системы Unix содержат лазейку, позволяющую взламывать такие скрипты. Это касается только скриптов, а не компилированных программ. В таких системах попытка запуска скрипта на Perl, для которого были выставлены s биты, приведет к появлению сообщения об ошибке со стороны самого Perl.

На таких системах вы имеете две возможности:

Можно исправить ядро так, чтобы запретить установку этих битов для файлов скриптов. Perl тем не менее будет правильно определять эти биты и устанавливать идентификатор пользователя. Подробную информацию об этом можно найти в Perl faq: ftp://rtfm.mit.edu/pub/usenet-by-group/comp.lang.perl/

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

#include <unistd.h>
void main () {
    execl("/usr/local/bin/perl","foo.pl","/local/web/cgi-bin/foo.pl",NULL);
}

После компилирования программы, выставте s биты. Программа будет выполняться с правами владельца, запускать интерпретатор Perl и выполнять скрипт, содержащийся в файле "foo.pl".

Кроме того, можно запускать сам сервер с правами пользователя, достаточными для выполнения необходимых действий. Если вы используете сервер CERN, то у вас есть возможность запускать сервер с разными правами для разных скриптов. См. документацию CERN для получения дальнейшей информации.

Автор: Дмитрий Громов
Взято отсюда: http://wmate.ru/publics/p_article84.html