http://www.theregister.co.uk/content/4/22382.html 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. - ISN is currently hosted by Attrition.org To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Tue Oct 23 2001 - 02:27:48 PDT