ch19_05.htm

By Tom Christiansen and Nathan Torkington ISBN 1-56592-243-3 First Edition, published August 1998

CLASS="programlisting"
><CODE
CLASS="userinput"
><B
><CODE
CLASS="replaceable"
><I
>Insecure dependency in open while running with -T switch at ...</I
></CODE
></B
></CODE
></PRE
><P
CLASS="para"
>This is because <CODE
CLASS="literal"
>$ARGV[0]</CODE
> (having come from outside your program) is not trustworthy. The only way to change tainted data into untainted data is by using regular expression backreferences:</P
><PRE
CLASS="programlisting"
>$file = $ARGV[0];                                   # $file tainted
unless ($file =~ m#^([\w.-]+)$#) {                  # $1 is untainted
    die &quot;filename '$file' has invalid characters.\n&quot;;
}
$file = $1;                                         # $file untainted</PRE
><P
CLASS="para"
>Tainted data can come from anything outside your program, such as from your program arguments or environment variables, the results of reading from filehandles or directory handles, and <CODE
CLASS="literal"
>stat</CODE
> or locale information. Operations considered insecure with tainted data include <CODE
CLASS="literal"
>system(STRING)</CODE
>, <CODE
CLASS="literal"
>exec(STRING)</CODE
>, backticks, <CODE
CLASS="literal"
>glob</CODE
>, <CODE
CLASS="literal"
>open</CODE
> with any mode except read-only, <CODE
CLASS="literal"
>unlink</CODE
>, <CODE
CLASS="literal"
>mkdir</CODE
>, <CODE
CLASS="literal"
>rmdir</CODE
>, <CODE
CLASS="literal"
>chown</CODE
>, <CODE
CLASS="literal"
>chmod</CODE
>, <CODE
CLASS="literal"
>umask</CODE
>, <CODE
CLASS="literal"
>link</CODE
>, <CODE
CLASS="literal"
>symlin</CODE
>k, the <B
CLASS="emphasis.bold"
>-s</B
> command-line switch, <CODE
CLASS="literal"
>kill</CODE
>, <CODE
CLASS="literal"
>require</CODE
>, <CODE
CLASS="literal"
>eval</CODE
>, <CODE
CLASS="literal"
>truncate</CODE
>, <CODE
CLASS="literal"
>ioctl</CODE
>, <CODE
CLASS="literal"
>fcntl</CODE
>, <CODE
CLASS="literal"
>socket</CODE
>, <CODE
CLASS="literal"
>socketpair</CODE
>, <CODE
CLASS="literal"
>bind</CODE
>, <CODE
CLASS="literal"
>connect</CODE
>, <CODE
CLASS="literal"
>chdir</CODE
>, <CODE
CLASS="literal"
>chroot</CODE
>, <CODE
CLASS="literal"
>setpgrp</CODE
>, <CODE
CLASS="literal"
>setpriority</CODE
>, and <CODE
CLASS="literal"
>syscall</CODE
>.</P
><P
CLASS="para"
>A common attack exploits what's known as a <EM
CLASS="emphasis"
>race condition</EM
><A
CLASS="indexterm"
NAME="ch19-idx-1000005439-0"
></A
>. That's a situation where, between two actions of yours, an attacker can race in and change something to make your program misbehave. A notorious race condition occurred in the way older Unix kernels ran setuid scripts: between the kernel reading the file to find which interpreter to run, and the now-setuid interpreter reading the file, a malicious person could substitute their own script.</P
><P
CLASS="para"
>Race conditions crop up even in apparently innocuous places. Consider what would happen if not one but many copies of the following code ran simultaneously.</P
><PRE
CLASS="programlisting"
>unless (-e $filename) {                     # WRONG!
    open(FH, &quot;&gt; $filename&quot;);
    # ...
}</PRE
><P
CLASS="para"
>There's a race between testing whether the file exists and opening it for writing. Still worse, if someone replaced the file with a link to something important, like one of your personal configuration files, the above code would erase that file. The correct way to do this is to do a non-destructive create with the <CODE
CLASS="literal"
>sysopen</CODE
> function, described in <A
CLASS="xref"
HREF="ch07_02.htm"
TITLE="Opening a File"
>Recipe 7.1</A
>.</P
><P
CLASS="para"
>A setuid CGI script runs with different permissions than the web server does. This lets the CGI script access resources (files, shadow password databases, etc) that it otherwise could not. This can be convenient, but it can also be dangerous. Weaknesses in setuid scripts may let crackers access not only files that the low-privilege web server user can access, but also any that could be accessed by the user the script runs as. For a poorly written setuid root script, this could let anyone change passwords, delete files, read credit card records, and other malicious acts. This is why you should always make sure your programs run with the lowest possible privilege, normally the user the web server runs as: <CODE
CLASS="literal"
>nobody</CODE
>.</P
><P
CLASS="para"
>Finally (and this recommendation may be the hardest to follow) be conscious of the physical path your network traffic takes. Are you sending passwords over an unencrypted connection? Do these unencrypted passwords travel through insecure networks? A form's PASSWORD input field only protects you from someone looking over your shoulder. Always use SSL when real passwords are involved. If you're serious about security, fire up your browser and a packet sniffer to see how easily your traffic is decoded. <A
CLASS="indexterm"
NAME="ch19-idx-1000005427-0"
></A
><A
CLASS="indexterm"
NAME="ch19-idx-1000005427-1"
></A
></P
></DIV
><DIV
CLASS="sect2"
><H3
CLASS="sect2"
><A
CLASS="title"
NAME="ch19-pgfId-432"
>See Also</A
></H3
><P
CLASS="para"
>The section on 
<A
CLASS="olink"
HREF="../prog/ch06_03.htm"
>&#13;"Cooperating with Strangers"</A
> 
in <A
CLASS="olink"
HREF="../prog/ch06_01.htm"
>Chapter 6</A
> of <A
CLASS="citetitle"
HREF="../prog/index.htm"
TITLE="Programming Perl"
><CITE
CLASS="citetitle"
>Programming Perl</CITE
></A
>; <I
CLASS="filename"
>perlsec </I
>(1); the CGI and HTTP specs and the CGI Security FAQ, all mentioned in the Introduction to this chapter; the section on "Avoiding Denial of Service Attacks" in the standard CGI module documentation; <A
CLASS="xref"
HREF="ch19_07.htm"
TITLE="Executing Commands Without Shell Escapes"
>Recipe 19.6</A
></P
></DIV
></DIV
><DIV
CLASS="htmlnav"
><P
></P
><HR
ALIGN="LEFT"
WIDTH="684"
TITLE="footer"><TABLE
WIDTH="684"
BORDER="0"
CELLSPACING="0"
CELLPADDING="0"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="228"
><A
CLASS="sect1"
HREF="ch19_04.htm"
TITLE="19.3. Fixing a 500 Server Error"
><IMG
SRC="../gifs/txtpreva.gif"
ALT="Previous: 19.3. Fixing a 500 Server Error"
BORDER="0"></A
></TD
><TD
ALIGN="CENTER"
VALIGN="TOP"
WIDTH="228"
><A
CLASS="book"
HREF="index.htm"
TITLE="Perl Cookbook"
><IMG
SRC="../gifs/txthome.gif"
ALT="Perl Cookbook"
BORDER="0"></A
></TD
><TD
ALIGN="RIGHT"
VALIGN="TOP"
WIDTH="228"
><A
CLASS="sect1"
HREF="ch19_06.htm"
TITLE="19.5. Making CGI Scripts Efficient"
><IMG
SRC="../gifs/txtnexta.gif"
ALT="Next: 19.5. Making CGI Scripts Efficient"
BORDER="0"></A
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="228"
>19.3. Fixing a 500 Server Error</TD
><TD
ALIGN="CENTER"
VALIGN="TOP"
WIDTH="228"
><A
CLASS="index"
HREF="index/index.htm"
TITLE="Book Index"
><IMG
SRC="../gifs/index.gif"
ALT="Book Index"
BORDER="0"></A
></TD
><TD
ALIGN="RIGHT"
VALIGN="TOP"
WIDTH="228"
>19.5. Making CGI Scripts Efficient</TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="684"
TITLE="footer"><FONT
SIZE="-1"
></DIV<!-- LIBRARY NAV BAR --> <img src="../gifs/smnavbar.gif" usemap="#library-map" border="0" alt="Library Navigation Links"><p> <a href="copyrght.htm">Copyright &copy; 2002</a> O'Reilly &amp; Associates. All rights reserved.</font> </p> <map name="library-map"> <area shape="rect" coords="1,0,85,94" href="../index.htm"><area shape="rect" coords="86,1,178,103" href="../lwp/index.htm"><area shape="rect" coords="180,0,265,103" href="../lperl/index.htm"><area shape="rect" coords="267,0,353,105" href="../perlnut/index.htm"><area shape="rect" coords="354,1,446,115" href="../prog/index.htm"><area shape="rect" coords="448,0,526,132" href="../tk/index.htm"><area shape="rect" coords="528,1,615,119" href="../cookbook/index.htm"><area shape="rect" coords="617,0,690,135" href="../pxml/index.htm"></map> </BODY
></HTML
>