activeX.file.system.object.txt

1999-08-17T00:00:00
ID PACKETSTORM:12192
Type packetstorm
Reporter Packet Storm
Modified 1999-08-17T00:00:00

Description

                                        
                                            `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  
*any* other user's ASP code, but also (with a small modification) stream  
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  
  
`