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



                     Xato Network Security, Inc.

                    www.xato.net



                     Security Advisory XATO-082000-01

                           August 17, 2000





        FRONTPAGE SERVER EXTENSIONS SHTML.EXE DENIAL OF SERVICE



                         --DOS Device DoS--





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



Systems Affected

================

FrontPage Server Extensions 1.1 for Windows 9.x, windows NT4, and Windows

2000





Overview

========

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.





Details

=======

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.





Impact

======

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.





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





Commentary

==========

Microsoft was informed of this issue on July 5, 2000.  Once acknowledged,

they

asked me to not release any advisory until they had could fix the problem.

They indicated that they would include the fix in the 1.2 version of the

server extensions.  Version 1.2 was released on August 15, 2000.



I was quite displeased that the release of the 1.2 extensions was rather

uneventful.  There was no security bulletin, it did not show up on the

FrontPage downloads site, it could not be found at the main downloads

page at microsoft.com.  There were also not any accompanying knowledge

base articles.  There were five security issues addressed in the

release and yet none of them were explained and there was no mention

at www.microsoft.com/security that there were security issues that have

been addressed with this release.  In other words, there are probably

hundreds of thousands of servers completely vulnerable to this DoS.



I thought it was bad enough that Microsoft sat on a known issue for so long,

yet when they finally did fix the issue it was with no notice to the

security community.  It was almost as if they were hoping to sneak the

issue by without all the bad press.



And finally, speaking for myself and the others who had informed Microsoft

of security issues in FPSE 1.2, it would be nice to have been given some

credit for the issues we discovered and worked with Microsoft to resolve.

We do not do this all for credit, but we are doing this on company time

and our companies should be given proper credit for the resources freely

given to help Microsoft test and secure their software.  Our companies

are paying for us to test someone else's software and credit is the

least they deserve.





































































Acknowledgements

================

Author:    sozni (sozni@xato.net)

Thanks to: Royce, tgooat, xentury, Mark Burnett, Don Staheli, Aaron Shumway





This document is located at:

http://www.xato.net/reference/xato-082000-01.htm

http://www.xato.net/reference/xato-082000-01.txt









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

THE INFORMATION PROVIDED IN THIS ADVISORY IS PROVIDED "AS IS" WITHOUT

WARRANTY OF ANY KIND. XATO NETWORK SECURITY, INC. DISCLAIMS ALL

WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF

MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.



COPYRIGHT (c) 2000 XATO NETWORK SECURITY, INC. ALL RIGHTS RESERVED.

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



Keywords:

FrontPage Server Extensions, Microsoft, Denial of Service, DoS,

Device Names, SHTML





Five Totally Unrelated Words:

Angst, Lagoon, Newt, Trample, Chimichanga