httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jennifer Myers <>
Subject Re: util.c hole and speed of security patch release
Date Tue, 23 Apr 1996 04:49:08 GMT

Rob Hartill writes:

> So Jennifer, phf-CGI-crap aside, is 1.0.3 vulnerable to newlines?

I hadn't looked before, and I'm not part of this latest IBM-ERS/CIAC
advisory, but this evening I gave it a shot.

I can only force an exploitation of the lack of the newline charcater
in escape_shell_cmd() in a really contrived way.  

escape_shell_cmd() seems to be a relic from the htbin
(pre-CGI) days: it escapes a script's argv[], on behalf of the htbin
writer.  Neither PATH_INFO nor QUERY_STRING is bothered to be escaped.

Only old, htbin-like scripts use argv[].  

Let's imagine that we had a htbin finger script written in perl which
we still choose to use (similar to the cgi-bin/finger script
distributed with NCSA and Apache httpd).

/cgi-bin/finger is essentially:

   echo Content-type: text/plain;
   /usr/ucb/finger "$*";

To exploit with a newline, we need to invoke a shell with argv. Let's
do that by rewriting /cgi-bin/finger in Perl (or we could use C) and
invoke finger with system():

  print("Content-type: text/plain\n\n");
  system("/usr/ucb/finger @ARGV");

(Note that this is purposely and contrivedly insecure).

Thanks to escape_shell_cmd(), occurences of ;&<> and the like 
will be escaped.  However, the newline will not.

Therefore we can abuse this, like:

and be given a shell.

is safe, in contrast).

*However*, since QUERY_STRING and PATH_INFO are not escaped like
argv is, anyone not from the dark ages knows not to trust the server
to escape your input for you.

I am not aware if there are any commonly-used CGI programs out there
which still use argv instead of QUERY_STRING.  *Even* if so, it is not
really an Apache problem (unless that script is distributed with
Apache - minor nit), as I doubt it is documented anywhere that you
can trust argv to be escaped by the server (and again, neither
PATH_INFO nor QUERY_STRING are).  I guess the guy at NASIRC has found
a CGI script which relies on argv not being escaped...

escape_shell_cmd() is also used to escape exec's in server-side
includes, but I doubt a problem lie therein: if it is enabled, the
evil scripter can already execute anything as user nobody.


View raw message