full-disclosure - NSFOCUS SA2003-05: Microsoft IIS ssinc.dllOver-long Filename Buffer Overflow Vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <187160-22003553020219375@M2W089.mail2web.com>
From: mattmurphy at kc.rr.com (mattmurphy@...rr.com)
Subject: NSFOCUS SA2003-05: Microsoft IIS ssinc.dllOver-long Filename Buffer Overflow Vulnerability

NSFOCUS Security Team wrote:
>> Vendor Status:
>> ==============
>> 
>> 2002.11.05  Inform vendor about the issue
>> 2003.05.28  Microsoft has issued a Security Bulletin(MS03-018) and the
related patch.
>
>
>More than six months to fix a buffer overflow - few can achieve this.
>This is trustworthy indeed.
>
>georgi

Georgi,

Please put aside your ridiculous prejudicial bullshit for a second, and
look at the facts.  What we have here is a buffer overrun in the SSI
interpreter of Microsoft IIS 5.0.  

Only one operating system is impacted, and even then you have to host
un-trusted SSI.  The only people doing this are hosting providers, and to
allow unsafe SSI out-of-the-box is a nightmare anyway as #exec cmd... can
do just as much damage.  That said, there are mechanisms to disable that
syntax.

Secondly, successful exploitation (crash or otherwise) requires the ability
to use an extended file name or create a virtual directory.  The first
scenario makes exploitation difficult; the attacker must use an extended
file name via the syntax documented in the CreateFile MSDN docs --
ssinc.dll apparently supports this, but this means that the file name will
be in Unicode -- another barrier to exploitation.  And, as described in
Microsoft KB article 247714, WebDAV could not be used to create such a file
/folder combination.  So, the only way to create such a file/folder
combination would be through FPSE, or a custom script in a language that
natively supported Unicode.  To my knowledge, the latter does not exist,
and the former is not possible by default.

The latter scenario is not possible on production servers.  Since creating
a virtual directory on Windows 2000 requires access to the IIS metabase,
and such access is restricted to Local Admins and/or LocalSystem, you'd be
insane to allow that. And, with un-fettered access to the IIS metabase, the
attacker could create the same virtual directory and install an Application
configuration that allowed ISAPI, and use the Low protection option.  The
combination of the two would yield simpler exploitation and the exact same
privileges.

Further, I have to question what you consider a good patch timeline.  Since
your site often includes things such as:

"Microsoft was notified on 17 March 2002.
They had 2 weeks to produce a patch but didn't."

(Quote from "Office XP Problems", Version 2.0)

However, one of the Microsoft competitors you personally use:

Server: Apache/1.3.26 (Unix)

took nearly 10 months to patch the shared memory user vulnerability, if
zen-parse's previous statements are accurate.  Also, they took more than 2
weeks to get a CVE candidate assigned to my report.

Open-source also doesn't suffer from afflictions called patching multiple
code bases, a deluge of bogus security bug reports, etc...

If you are going to gripe, at least have a good reason to do so.

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .