💾 Archived View for gemini.spam.works › mirrors › textfiles › hacking › MICROSOFT › ax.txt captured on 2022-06-12 at 08:48:38.

View Raw

More Information

-=-=-=-=-=-=-

Date: Thu, 11 Feb 1999 17:37:18 -0500
From: Gary Geisbert <gary@NEWSLETTERS.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Using FSO in ASP to view just about anything


This active server page opens the FileSystemObject and streams the contents
of the file specified in the "file" parameter.  The problem with FSO is that
you can go 'outside' of the "\InetPub\wwwRoot\" directory using "../".

e.g.
http://www.server.foo/showfile.asp?file=../../global.asa

Another problem is that since the file is being read with a TextStream, ASP
code will not be executed.  So if the file specified is an ASP file, the
results will be similar to the ::$DATA exploit.

For example: If this file was placed on the server of a web hosting company
who allows ASP, a malicious user could use it not only to view the source of

data into other users' ASP files.  This would essentially overwrite whatever
is currently there.


-------[ cut here: showfile.asp ]-------

<%
' grab the file from the URL
FileName = Request.QueryString("file")

' create the filesystemobject and open the file
Set fso = CreateObject("Scripting.FileSystemObject")
Set ts = fso.OpenTextFile(Server.MapPath(FileName))

' read the contents
ShowTheFreakinThing = ts.ReadAll

' display them
Response.Write ShowTheFreakinThing

' EOF
%>

-------[ cut here: showfile.asp ]-------

That's about it.  Email me if you have questions.

-Gary Geisbert (gary@newsletters.com)

--------------------------------------------------------------------

Date: Thu, 11 Feb 1999 16:25:46 -0700
From: Joel Maslak <jmaslak@WIND-RIVER.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: Using FSO in ASP to view just about anything

At 05:37 p.m. 11/02/99 -0500, you wrote:
>This active server page opens the FileSystemObject and streams the contents
>of the file specified in the "file" parameter.  The problem with FSO is that
>you can go 'outside' of the "\InetPub\wwwRoot\" directory using "../".

Yes, this is a fairly well known bug.

Solution?  NTFS permissions.  Simply run each virtual web as a different
user, and make sure that user can't view each other's virtual webs, but
only it's own virtual web.  This feature is actually quite useful when you
need to "break out of the mold" of traditional design.

One thing that should be noted is ANY ActiveX server can be executed by a
user, by simply doing a server.CreateObject in the ASP file.  Obviously,
the security ramifications of this can be quite severe.  You can open up MS
Outlook, and using the mail object, send mail.  Neat feature for some
people, but scarry if you look at some the other interfaces in some of your
applications (think attachments!)...  Do your users really have a
legitimate purpose in starting up, say, Word (never tried this, but I bet
it would work).  This is a much bigger issue.  An example of this use is at:
        http://www.swynk.com/friends/datema/excelface.asp

It would be nice to have a way of limiting what objects can be created by
server.CreateObject (yes, I realize this is probably a big modification).

In addition to this feature, how about...

<!-- #include file="..\ANYDIR\ANYFILE.DAT" -->

You might be able to get access to any file stored on the server w/o
sufficient permissions (think credit card orders).



Joel Maslak
UPDATE -- Generate Web Traffic
http://www.permission-marketing.com/

--------------------------------------------------------------------

Date: Fri, 12 Feb 1999 10:51:07 -0500
From: Russ <Russ.Cooper@RC.ON.CA>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: Using FSO in ASP to view just about anything

Folks,

I would appreciate it if people would send their responses to Gary
(gary@newsletters.com) and I would ask Gary to summarize to the list.

I let Gary's message out not because it was a bug (and to that extent, I
should have asked Joel to change his message), but because it does
represent a reasonable vulnerability that could be easily overlooked.

In the meantime;

Phillip R. Paradis <paradis@exploremaine.com> said...
This exploit does not work in IIS4 if you deactivate the Allow Parent
Paths option in Internet Services Manager. Under the application root
properties, select configuration, app options, and deselect Allow Parent
Paths. This prevents MapPath from resolving anything with a .. in it.

Martin DEVERA <devik@cdi.cz> said...
>It would be nice to have a way of limiting what objects can be created
by
>server.CreateObject (yes, I realize this is probably a big
modification).

there is a way, you can set perms to a registry value
HKCR\Classes\{YourID} and so disallow particular user groups to read it.
It effectively disables user to create an object.

Cheers,
Russ - NTBugtraq moderator