[25143] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Microsoft IIS 5.0 CodeBrws.asp Source Disclosure

daemon@ATHENA.MIT.EDU (Chris Anley)
Thu Apr 18 17:41:20 2002

Message-ID: <037f01c1e6bb$35dc7e00$4201010a@kodiak>
From: "Chris Anley" <chris@ngssoftware.com>
To: <bugtraq@securityfocus.com>
Date: Thu, 18 Apr 2002 10:27:04 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

The restriction to .asp, .htm, .html and .inc doesn't work, because there's
an off by one error, and there's an interesting behaviour of
server.mappath() that might easily trip folks up when writing code to verify
paths.

When you submit a path to server.mappath() that contains parent path
character sequences ("/../" or one of the many unicode equivalents) it seems
that the preceding "directory" is cancelled from the path without first
verifying its existence. This means that you can put (almost) any string you
like into a path that is going to be passed to server.mappath() and, as long
as you 'cancel' it out, you can still wind up opening the file of your
choice. As an example, this is the path to open the source code to
codebrws.asp itself:

http://10.1.1.1/IIsSamples/SDK/asp/docs/CodeBrws.asp?source=/IIsSamples/SDK/
asp/docs/codebrws.asp

This is a path that does exactly the same thing, but the path contains the
string "foo.html":

http://10.1.1.1/IIsSamples/SDK/asp/docs/CodeBrws.asp?source=/IIsSamples/SDK/
asp/foo.html/%c0%ae%c0%ae/docs/codebrws.asp

From the implementation of 'fValidPath' you can see that it's easy to be
tripped up by this. If this code:

         If InStr(dwLen-5,strPath,".html",1) Then
             SomeKnownExtension = true
         End If

Had been this code:

         If InStr(1,strPath,".html",1) Then
             SomeKnownExtension = true
         End If

...you could use codebrws.asp to browse any text file. So if an asp app is
verifying a path on the basis that it contains some string, and doesn't
contain "..", it's probably broken.

The codebrws code takes the right approach; making the test more stringent
by checking the string at some offset. Unfortunately there's an off-by one
error; it should be dwLen-4 rather than dwLen-5. The implication is that we
can browse any file that ends in

.html
.htm
.asp
.inc

...with an extra character on the end. This has an immediate implication for
servers using the new .net framework, in which the '.aspx' file extension is
used.

None of this is all that serious, I just thought it was interesting in an
"input validation" kinda way...

     -chris.

----- Original Message -----
From: "H D Moore" <hdm@digitaloffense.net>
To: "Randy Hinders" <rahinders@hotmail.com>; <sflist@digitaloffense.net>;
<bugtraq@securityfocus.com>
Cc: <vulnwatch@vulnwatch.org>
Sent: Wednesday, April 17, 2002 1:27 PM
Subject: Re: Microsoft IIS 5.0 CodeBrws.asp Source Disclosure


> Right, you can only access files ending in the four "allowed" extensions.
> These extensions are: .asp, .inc, .htm, and .html.
>
> -HD
>
> On Wednesday 17 April 2002 07:25 am, Randy Hinders wrote:
> > While checking various files and extensions I wanted to ensure that
other
> > files were still "protected" from this.  I was not able to read the
> > global.asa but was able to read (as expected) other asp pages..
> >
> >
http://localhost//iissamples/sdk/asp/docs/CodeBrws.asp?Source=/IISSAMPLES/%
> >c0%ae%c0%ae/global.asa Returned "View Active Server Page Source-- Access
> > Denied" to the browser.
> >
> >
http://localhost//iissamples/sdk/asp/docs/CodeBrws.asp?Source=/IISSAMPLES/%
> >c0%ae%c0%ae/iisstart.asp Returned the source code to the browser.
>


home help back first fref pref prev next nref lref last post