COMMAND
aps
SYSTEMS AFFECTED
Windows NT
PROBLEM
Gary Geisbert found following. 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.
<%
' 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
%>
SOLUTION
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.
A way of limiting what objects can be created by
server.CreateObject is to 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.