MS issues bum security patch, contradicts self

From: Thomas C. Greene (tcgreene@bellatlantic.net)
Date: 10/22/01 

From: "Thomas C. Greene" <tcgreene@bellatlantic.net>
To: "Bugtraq@Securityfocus. Com" <bugtraq@securityfocus.com>, <focus-ms@securityfocus.com>
Subject: MS issues bum security patch, contradicts self
Date: Mon, 22 Oct 2001 06:24:25 -0400
Message-ID: <NFBBLAEICLEBFNIBCMKMEEKECGAA.tcgreene@bellatlantic.net>

http://www.theregister.co.uk/content/4/22382.html

MS issues bum security patch, contradicts self
Why full disclosure is good
By Thomas C Greene in Washington
Posted: 22/10/2001 at 10:00 GMT

Recently-issued patches for an exploitable RDP (Remote Data Protocol) bug in
Win-NT and 2K have given users trouble enough for MS to yank one of them
(details below). The timing is unfortunate. Only last week Microsoft
Security Manager Scott Culp called on outside security researchers to follow
Redmond's no-tell bug reporting example
http://www.theregister.co.uk/content/55/22332.html.

One core issue is exploit code, and the examples are Nimda and Code Red.
"It's high time the security community stopped providing blueprints for
building these weapons," Culp said.

His aim is to keep exploitable data out of the hands of the Blackhat
development community, which, while perfectly legitimate, is a fairly shaky
proposition in practical terms. Blackhats are often well ahead of vendors,
as we've seen many times.

We certainly don't advocate broadcasting step-by-step exploit manuals --
especially by the mainstream press and by security vendors which stand to
profit from abuse; but we believe that the tech press and independent
security lists should continue to publish detailed information. We wish
Microsoft would contribute the data they find, at least after a patch has
been issued.

We say this because system configurations vary and it's important to verify
that a given patch actually does the job in each case. Withholding the
information needed to prove that it works forces admins to trust that it
does. This can produce a false sense of security, which is worse than
incomplete security of which one is, at least, aware.

For rigorous evaluation we need two things: a detailed description of the
bug, and as many working exploits as we can find to run against the patch.
Only then can we be confident that a patch is robust.

"Without exploit code, how do we ensure that the patches actually work,"
VulnWatch http://www.vulnwatch.org moderator Steve Manzuik asked in a recent
letter to Culp.

"Trust our vendor? I don't think so. Vendors have proven that they bow to
stock prices and market pressures and will continue to do this over and
above security needs. Multiple vendors, not just Microsoft, have also proved
that they will not completely research the issues themselves, and release
insufficient patches," Manzuik says.

Funny that
Talk about insufficient patches. MS concludes that the NT version of their
RDP-bug patch can be installed safely, while the 2K patch will make a mess
of your system and has been removed from the TechWeb site pending a fix.

If you've downloaded the 2K patch and not yet installed it, then you should
discard it before some well-meaning OFH ninny goes ahead with the
installation for you.

The patch is not crucial as the RDP hole can't (yet) be exploited in a
destructive manner. A "particular series of data packets" will shut the
server down, but a simple re-boot is all that's needed to bring things back.
Of course, if one's being deliberately attacked with this vulnerability,
re-booting every fifteen minutes pretty much equals a denial of service.

The systems affected are: NT Server 4.0, Terminal Server Edition; 2K Server;
2K Advanced Server; and 2K Datacenter Server. The NT patch is available here
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/
bulletin/ms01-052.asp; and the 2K patch will be posted as soon as possible,
MS says.

It would be nice if MS would specify the 'particular series of packets'
which triggers the RDP freeze, as it's quite possible there's a simple
workaround which might be applied as a stopgap. It would also be nice to run
an attack against one's own machine after patching, to ensure that the fix
is effective on one's system.

But that would require us to regard exploit code as a tool, not a weapon.
Unfortunately it's both, which is why it may never be possible to reconcile
these two quite legitimate, and eternally conflicting, points of view. ®

Relevant Pages