httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: Bug?
Date Mon, 29 Jul 1996 09:13:47 GMT
Alexei Kosut wrote:
> 
> On Sun, 28 Jul 1996, Ben Laurie wrote:
> 
> > Because its easier. argv[1] is shorter than getenv("QUERY_STRING") and a pile
> > of stuff to parse it. It also means that I can test the CGIs more easily. OK,
> > so I'm being lazy, but isn't that what software is for?
> 
> So write more software. Don't break existing software.

I had no intention of breaking existing software. Its just that I thought this
behaviour was introduced by the spurious security hole patch.

> 
> > And since I do use them, it ain't true that noone uses them anymore ;-)
> 
> You're probably right. In fact, I know you're right. That's exactly why
> the behavior *has* to stay the way it is. Because it's defined that way.
> If you take a look at the original CGI spec, on either NCSA or CERN's
> sites (probably David Robinson's internet draft, too), you'll see that
> argv is defined as being shell-escaped arguments.

I've just checked (at NCSA, CERN points me to W3 which is currently buggered),
and the spec reveals why there's nothing passed on the command line when
there's an '=' in the query (that is, it says "when there's an '=' in the
query don't pass anything on the command line". This is perverse in my view,
but that is what it says). However, as far as I can see, it says nothing about
escaping. In fact it hardly says anything about anything. It could be that it
was "improved" during the transition to a groovy HTML-ized document. Do you
know where the original flat text version is?

> 
> People are no doubt passing these arguments directly to the shell.

I don't really understand what you mean by this.

> The
> cgi-bin and cgi-src programs that NCSA and Apache including with their
> distributions for years did exactly that. Rememeber all those CERT
> advisories? Those came about exactly because we didn't escape *enough*
> characters. If we remove the escaping, then suddenly a lot of CGI scripts
> become targets for attack. Oops.

The advisories that I remember fell into two classes. Those that warned of
dodgy CGI binaries which didn't take sufficient care, and those that spuriously
claimed that Apache itself had a security hole, which we corrected but then
decided was not, in fact, true. The problem I've got is that I can't remember
what we actually changed. I do know that we didn't change it back.

> 
> I will veto any change that makes Apache incompatible with the CGI/1.1
> spec.

So far, I have no evidence that this change is incompatible.

Cheers,

Ben.

> 
> -- Alexei Kosut <akosut@organic.com>            The Apache HTTP Server 
>    http://www.nueva.pvt.k12.ca.us/~akosut/      http://www.apache.org/
> 

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.            Apache Group member (http://www.apache.org)

Mime
View raw message