[17297] in bugtraq
Re: Microsoft Security Bulletin (MS00-078)
daemon@ATHENA.MIT.EDU (Luiz Lima)
Mon Oct 23 13:22:00 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
Message-Id: <001c01c03b06$b3abd7c0$c476e0c8@luizlima.com>
Date: Sat, 21 Oct 2000 00:29:11 -0200
Reply-To: Luiz Lima <llima@IMAGELINK.COM.BR>
From: Luiz Lima <llima@IMAGELINK.COM.BR>
X-To: Microsoft Security Response Center <secure@microsoft.com>
To: BUGTRAQ@SECURITYFOCUS.COM
So, to solve a security issue, Microsoft has decided how I can or can't name
my own folders? Specially when ".com" is the most widely used TLD on the
Internet, did it ever occur that an ISP and webdeveloper company could have
literaly hundreds or thousands of folders named "something.com" to host
websites still under development and/or part of a portfolio? Can you
honestly tell me that locking the drawer with the key inside is the best
patch you can provide?
Please, don't reply saying YES to any of these retorical questions... Please
offer a solution (which doesn't include being vulnerable again) instead.
---
Luiz Lima
Image Link Internet
http://www.imagelink.com.br
----- Original Message -----
From: "Microsoft Security Response Center" <secure@microsoft.com>
To: "'Luiz Lima'" <llima@IMAGELINK.COM.BR>; <BUGTRAQ@SECURITYFOCUS.COM>
Cc: "Microsoft Security Response Center" <secure@microsoft.com>
Sent: Friday, October 20, 2000 11:39 PM
Subject: RE: Microsoft Security Bulletin (MS00-078)
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Hi All -
>
> This is expected behavior, although it requires some explanation.
>
> Security Bulletin MS00-030 ("Malformed Extension Data in URL")
> provided a patch that changes how certain URLs are handled. One of
> the changes is that after applying the patch, directory names can't
> include an extension that's normally associated with an executable
> file type. So, for instance, http://localhost/test.com/index.htm
> would be treated as invalid, while
> http://localhost/test.aaa/index.htm would be treated as valid. We
> did discuss this in the original version of MS00-030, but today we
> updated it to make it more clear. (See "What Does This Patch Do?" in
> the FAQ)
>
> The next question is why applying the patch for MS00-078 caused the
> behavior from MS00-030 to occur. The reason is that both of the
> patches shipped their new functinality via W3SVC.DLL. Whenever we
> issue a patch, the fix is incorporated into the official code tree.
> Future patches are always built using the then-current code tree.
> This means that, when we issued MS00-030, the new URL handling became
> part of the code tree for W3SVC.DLL. When we issued the patch for
> MS00-078, it contained a fix for its vulnerability, built atop the
> current code tree, which already included the functionality for
> MS00-030. (BTW, to be 100% accurate, there actually isn't a new
> patch for MS00-078 -- the bulletin points to the patch delivered in
> MS00-057. I glossed over this detail because the description was
> complicated enough already).
>
> One last point. This does *not* mean that all security patches are
> cumulative. MS00-030 and MS00-078 shared behavior only because they
> both shipped W3SVC.DLL. If, for example, MS00-078 had included
> XYZ.DLL rather than W3SVC.DLL, the behavior from MS00-030 would not
> have been included in it.
>
> Hope that helps clear up the mystery. Regards,
>
> Scott Culp
> Security Program Manager
> Microsoft Security Response Center
