COMMAND
FPSE
SYSTEMS AFFECTED
FrontPage Server Extensions 1.1 for Win9.x, WinNT4 and Win2000
PROBLEM
Following is based on a Xato Network Security Security Advisory
XATO-082000-01. The FrontPage Server Extensions are vulnerable
to a remote denial of service attack that will disable all
FrontPage operations on a web site. By requesting a URL that
includes a DOS device name, the server extensions will hang and
will not service any further requests. To re-enable the server
extensions requires restarting IIS or rebooting the server.
There is also a secondary problem with certain DOS device names
that reveal the server's physical path.
To exploit this vulnerability, you must request a URL through the
shtml.exe component of the FrontPage Server Extensions. The URL
you request must include a DOS device name followed with the .htm
extension.
The following DOS devices will lock up the server extensions:
http://www.example.com/_vti_bin/shtml.exe/com1.htm (if the server has a com1)
http://www.example.com/_vti_bin/shtml.exe/prn.htm
http://www.example.com/_vti_bin/shtml.exe/aux.htm
Note also that the following URL's will also have the same effect:
http://www.example.com/_vti_bin/shtml.exe/prn.anything.here.htm
http://www.example.com/_vti_bin/shtml.exe/com1.asp
http://www.example.com/_vti_bin/shtml.exe/com1.
However, the following URL's will NOT have any affect on the
server:
http://www.example.com/_vti_bin/shtml.exe/prn
http://www.example.com/_vti_bin/shtml.exe/com1
http://www.example.com/_vti_bin/shtml.exe/aux
Also note that the device names MAILSLOT, PIPE, and UNC do not
have the denial of service effect. However, they do have an
interesting side-effect that they do return the physical path to
the server. If you send the request:
http://www.example.com/_vti_bin/shtml.exe/pipe.htm
You will receive the following error:
Cannot open "C:\InetPub\wwwroot\pipe.htm": no such file or folder.
Finally, using the device name NUL (as you would expect) returns
a blank page.
When one of the above URL's are sent to the server, all FrontPage
operations become disabled for that web site. If the web server
hosts multiple web sites, only the one that received the request
will become disabled.
By disabling the FrontPage Server Extensions, you block all web
authoring, web administration, WebFolders, InterDev, and WebBot
operations. The server will otherwise function normally until the
IIS Service is restarted.
Note that there is another related issue when using the vti_rpc
list_documents method that includes a reference to a DoS device.
However, since one would need authoring permissions to issue that
command, it is not much of a threat.
So how is this all important to you? Lets go over some scenarios:
SCENARIO 1: The Everlasting Hack
=================================
Suppose that Company X has a web site hosted at a large web
hosting service that allows their customers to author their sites
using FrontPage. And suppose that as a further security
precaution, that hosting service has shut off telnet and FTP
access, forcing users to author with the FrontPage client. One
day the CEO and the web designer get into an argument and the CEO
fires the web designer.
As a going away present, the web designer posts on the company
home page some pictures of the CEO drunk at a company party. He
then sends the site a FP DoS and packs up his personal belongings.
Needless to say, the CEO begins to get calls about his web site
and quickly opens his FrontPage client to undo the web designer's
changes. To his demise, he is unable to connect to the site so
he calls the tech support at the hosting service. The technician
says that permissions seems ok and the FrontPage extensions are
working properly on all the other sites. He suggests to the CEO
that the problem may be with his FrontPage client. The CEO panics
as he reinstalls FrontPage on his own computer and after a day of
calls back and forth, he finally convinces one of the technicians
to completely take down the company site until the problem is
fixed. Finally, someone reads the Xato advisory and sees the
problem and that they must completely restart the IIS server to
get the FrontPage extensions working again.
SCENARIO 2: Bad Sales Day
==========================
Several months have passed and the CEO of Company X has learned
that his former web designer had stolen company secrets and sold
them to a competitor, Company Y. Company Y is now ready to come
out with a product using all of Company X's ideas. The CEO of
Company X is irate but instead of spending years in litigation,
he decides to get some revenge. He notices that Company Y uses
the FrontPage Form Bot to take product orders online. He waits
until the release date of Company Y's new product and sends the
FrontPage DoS, disabling the order form.
By mid-morning, Company Y notices that there have been no sales
at all for their new product. They check their web site and it
seems to be up and running. They even browse to the order form
page which also comes up properly. They spend half the day
trying to figure out why they are not getting any orders when
they finally get an e-mail complaining that their order form gets
an error when you click on the submit button. After a couple
more hours of debugging, they finally reboot the server, having
lost nearly a whole day of sales.
SCENARIO 3: Killing the Client
===============================
But the CEO of Company X isn't finished with them yet. He keeps
checking for the url www.company-y.com/_vti_pvt/service.lck.
Once that file appears, he knows that someone has the web site
open for authoring in the FrontPage client. Once he sees that
file, he once again sends the FP DoS. Meanwhile, the web designer
is working hard on some new designs for the web site. He has
several pages open that he is working on and after things look
just right he goes to save his work. He clicks on save and sits
there. After a minute or so waiting, he clicks on save again.
Something is obviously wrong so he switches to a web browser to
see if the site is up. Sure enough, it is up and running. But
now when he switches back to FrontPage, the screen won't refresh.
Eventually he has to use CTRL+ALT+DEL to stop FrontPage and loses
all his work. Dismayed, he starts up again and now he can't even
connect to the server. Time for another reboot.
Daniel added following. Windows 2000 (IIS 5.0) and FrontPage 2000
extensions - while GET with DOS device in name is ACTIVE, server
shows 100% cpu utilization, but still works and serves other
requests. After HTTP GET time out, everything is back to normal
and everything _works_ (so no need to restart anything). Still it
makes computer go to 100% CPU utilization, so IT IS threat. This
is true for any combination shown by sozni in his report.
SOLUTION
Microsoft has addressed these issues in the 1.2 version of the
FrontPage server extensions available at:
http://msdn.microsoft.com/workshop/languages/fp/2000/winfpse.asp