[13834] in bugtraq
Re: CGI.pm and the untrusted-URL problem
daemon@ATHENA.MIT.EDU (Marc Slemko)
Tue Feb 15 13:57:39 2000
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.BSF.4.20.0002141225100.357-100000@alive.znep.com>
Date: Mon, 14 Feb 2000 12:46:06 -0700
Reply-To: Marc Slemko <marcs@ZNEP.COM>
From: Marc Slemko <marcs@ZNEP.COM>
X-To: Kragen Sitaker <kragen@pobox.com>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.GSO.4.21.0002141129470.18255-100000@kirk.dnaco.net>
On Mon, 14 Feb 2000, Kragen Sitaker wrote:
> Diagnosis
> ---------
>
> It appears that this happens because the unencoded space is interpreted
> by the HTTP server (Apache 1.3.6 in my tests) as separating the URL
> from the protocol name. So the environment variable SERVER_PROTOCOL
> gets set to everything following the space, followed by a space and the
> actual protocol, such as "HTTP/1.0".
Correct, this does appear to be a bug. I suspect that a lot of such bugs
will be found. Unfortunately.
However it is important to note that this does not exploit a bug in
Apache. Apache is choosing to deal with an illegal request in a perfectly
legitimate manner. At least, that is my understanding of what the spec
says; I haven't checked it closely WRT this particular issue.
Part of Apache's functionality is to pass unknown methods and protocols on
to CGIs. It is be arguable that Apache should explicitly reject any
request with more than two unencoded spaces in it.
> Three of the four tested browsers (Netscape 4.6, MSIE 3.0, and Mozilla
> M12) send the unencoded space in the request URL, which generates an
> illegal HTTP Request-Line.
>
> CGI.pm simply takes that environment variable, chops off everything
> from the slash onwards, lowercases it, and returns the result as the
> URL scheme.
>
> Suggested fixes
> ---------------
>
> RFC 1738 and RFC 2068 say that only a-z, 0-9, "+", ".",
> and "-" are allowed in scheme names. Accordingly, I suggest the
> following change to CGI.pm:
Or it could simple properly encode things, as it should do for all data
supplied by the user that is output.
Filtering is often easier, however, as encoding can be very context
sensitive.
> The successful exploit requires a remarkable chain of extreme forgiveness:
> 1- The web browser must accept an illegal URL from (possibly valid,
> although very unusual) HTML.
> 2- The web browser must send an illegal HTTP request with the illegal
> URL, without %-encoding the URL to make it legal.
Note that IE appears to be far better in making sure it only makes legal
requests. Good job Microsoft, in this particular situation. Too bad IE
still has a nasty security hole caused by IE trying to guess the MIME
type, which means that you can't output any text/plain content that has
user-supplied data because you can't encode it (since it is text/plain)
and you never know when IE will try to guess what MIME type it thinks it
is. The latter more than cancels out the former.
There is at least one other serious issue caused by Navigator sending
bogus HTTP requests that is completely server independent and that the
server can do nothing about. I will post details later this week when I
get a chance.
