[Mongrel] bad URI(is not URI?): c:\boot.ini

Zed A. Shaw zedshaw at zedshaw.com
Thu Mar 8 20:27:41 EST 2007

On Thu, 8 Mar 2007 13:33:11 -0600
"Berger, Daniel" <Daniel.Berger at Qwest.com> wrote:

> > I'll probably make this optional then for those people who 
> > don't care about IE on a localhost setup.
> Is this something that needs to be fixed in the URI module, i.e.
> handling Windows-style file URL's? Or should I just nevermind?

No, it's more of an opening for an attack based on malformed URLs than

Normally, let's say you do a request for:

GET /<something horrible>/../c:\system.ini HTTP/1.1

Then Mongrel will take the <something horrible> and reject it since it
most likely is a parsing error.  This is why mongrel so easily defends
against a lot of attacks.  Not because it's actively trying, but just
by being strict.

The problem comes from an ambiguity in the RFC that says requests with:

GET http://localhost:3000/<something horrible>/../c:\system.ini HTTP/1.1

Are not valid, but still need to be processed by servers since clients
still try to use it.  The above line is intended for proxy servers
only, not end point web servers.  Mongrel isn't a proxy server, so all
this host information is useless.  The RFC is also ambiguous on which
host specification should win when this and a Host: header is given.

What happens is IE for various weird reasons insists on sending this as
its GET request.  Since people running rails on IE typically don't put
it behind a proxying server these requests aren't scrubbed so they blow
up.  Nothing they can do, and the only fix is to either reject these
outright or try parsing the requested URI to pull off the path and
request portions dropping the host and protocol junk.

Well, that's where the trouble lurks.  If the quality of cgi.rb is any
indicator, Ruby's URI parsing could have all sorts of
vulnerabilities.  It's not written using a parser so it's not easy to
validate correctness (you can look at mongrel's parser and check it
right away against the RFC).  Now that there's some attack available
for these kinds of URLs that only IE and Windows servers process
validly I begin to worry how long it'll be before there's an attack.

Then again I'm paranoid, but my paranoia has paid off for many people
and been right many times before.

So, long story short, there's nothing you can do unless you can fix
IE.  Only thing I'm going to do is add an option to reject these kinds
of URLs with the full host as attacks, and then see what happens. 

Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book

More information about the Mongrel-users mailing list