httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: WWW Form Bug Report: "Security hole in test-cgi" on Linux
Date Sun, 02 Jun 1996 01:43:29 GMT
On Sat, 1 Jun 1996, Brian Behlendorf wrote:

> Hmm, I couldn't replicate his problem, but given that test-cgi is a SH 
> script, maybe it shouldn't be in there, particularly since "printenv" 
> (the only other script now in cgi-bin by default) does roughly the same 
> thing.

I can replicate it. Easily. On thousands of Apache systems across the
world.It's an interesting hole. Certainly there's nothing that Apache
can do, since potentially *any* of the variables test-cgi shows will
do that. If we checked the method (as NCSA httpd 1.5.1, at least,
seems to do - not directly for this purpose, but a method of "*" gets
translated to "HTTP" somewhere along the line.), you can still throw in
a Content-location header with "*". Same result.

You can also use fun things like "/*", followed by "/*/*" and
"/*/*/*", etc, etc and get yourself a complete directory listing. Does
this count as a serious security hole yet? Problem is, "/*" might in
fact *be* a legal, say, content type. Case in point: "*/*" is a
perfectly legal Accept: value (it's the default, in fact). We can't
really do anything about passing that on to a CGI script...

Yet another reason not to use shell scripts, I guess.

P.S. Actually, *scratches head*, I can't seem to replicate this on any
NCSA servers. Is it possible they do check for this before sending on
to CGI scripts? As I mentioned, it does normalize protocol versions,
but the Content-length approach doesn't work either. 'Course, I only
tried about three of them (hoohoo, plus two picked at random from
Netcraft's survey), and they may just be machines on OSes that have
shells that don't expand environment variables. 


Alexei Kosut <>      The Apache HTTP Server
      "War does not determine who is right, only who is left."

View raw message