Slashdot Mirror
Internet Draft on Vulnerability Disclosures
Cowboy71 writes: "An interesting posting on Bugtraq by Stephen Christie announcing the release for comment of an internet-draft "Responsible Disclosure Process" document, prepared by himself and Chris Wysopal of @stake. You can view the full paper at the IETF site."
OK, I've made an attempt to read the document critically. It reminded me of some of its more obvious failings though:
I have to admit that it's a good general solution for presentation to and ratification by the Microsofts of this world - companies for whom marketing departments have more control over release dates than systems engineering or test departments...
...but these are the very companies that are LEAST likely to pay attention to the words of the technological minority, in favour of placating the fickle majority. Anyone else see a problem here??
jer
We may be human, but we're still animals
- Steve Vai
- Vendor: the producer of software in which vulnerabilities are discovered (e.g. Microsoft)
- Reporter: someone who finds a security hole (typically someone in the "security community")
- Coordinator: someone who mediates between Reporters and Vendors
- Customer: end-user of vendor products
- Security Community: the usual researchers, sysadmins, etc. who are trying to improve overall information technology security (it doesn't say whose security).
The first thing I notice is that while there are several places where it says the vendor MUST do this or that (e.g. the vendor MUST respond to vulnerability reports within 7 days), and several things the reporter SHOULD do (the reporter SHOULD provide Vendor with all known details of the issue), there's nothing the reporter MUST do. So it's not an attempt to impose mandatory policies on reporters through a standards process.The recommendations make a reasonable attempt to protect vendors and customers (i.e. it doesn't go for the zealous instant-full-disclosure approach) without allowing reports to go ignored for too long. It basically says the vendor should get 7 days to initially respond to the report, then 30 days to fix the problem, and then can request a 30 day grace period to get the fix out to customers before the reporter releases details to the public . If the reporter goes along with this, the vendor must credit the reporter in its own public announcement of the fix.
It's kind of weird, seeing an internet draft using protocol-like terminology to describe how people and companies (rather than computers) are supposed to interact with one another. I hope this isn't supposed to be an RFC, or else that this kind of thing is normal for the IETF (I haven't read that many IETF docs). I've never seen a thing like this and it seems to turn the IETF into an even more political body than it already is. I thought the IETF was supposed to make recommendations about bits and packets, not people and companies.
Anyway, I can take issue with some of the points in the document, but at first glance there's nothing in it that I'd call outrageous. It seems like a genuine effort to find a good intermediate policy between instant full disclosure (and instant widespread exploits) and leaving stuff secret forever (letting exploits spread without the public knowing). Whether that policy is the optimal one is of course a matter of opinion and reasonable people can differ on it.
The document's authors came from several different camps (two names I recognize are Bruce Schneier's co-author Adam Shostack (presumably on the full disclosure side), and Microsoft's Scott Culp representing the Evil Empire) and it looks like they managed to arrive at a consensus. I guess that's a good sign and I hope Bruce and/or Adam will publish their own opinions of the draft soon.
This document seems to downplay the role of public disclosure, and instead inserts the coordinators as the middlemen between reporters and vendors. This is fine for Bugtraq, CERT, and all the other so-called "coordinators," but where does that leave the public? Several times, the document addresses public disclosure, but only in the vein that vendors can choose to withhold recognition or other feedback if a reporter chooses to go public with the information.
I think this document is a big win for the coordinators, but a big loser for the public.
It also denies admins the opportunity to at least shut down or wall off the affected service until a real fix is available.
pr0n - keeping monitor glass spotless since 1981.
One subject that is avoided, and when hit upon is looked down on, is that sometimes vendors refuse to respond and reporters release information publicly. If a vendor is unresponsive and refuses to do anything about a vulnerability there is usually very little a reporter can do to get that vulnerability fixed. If there is no vendor receipt a coordinator should be contacted. If there is still no response then the vendor should be notified that if there is no resonable reply that indicates effort to fix the vulnerability then information about the vulnerability will be released publicly after a grace period of about 15 days (long enough for a reply but short enough to decrease those vulnerable). If they are still unresponsive then the responsible thing to do is to get the information out there and to make an effort to force them to fix the vulnerability. This method should be avoided if at all possible because it causes a quick and less thought out fix to the problem. It is, however, better than leaving the vulnerability open to others who have discovered the vulnerability or will do so and exploit the unknowing users.
That's possible, but I don't really think so. @stake obviously has roots in the non-corporate security community, so we know that they're aware of the benefits of disclosure. It is possible that they are angling for an RFC as a means of protecting amature security researchers who want to disclose what they find without suffering the fate of Dimitry Sklyarov. After that debacle, many people stopped disclosing anything because it was obvious that the DMCA would be used to make their lives miserable if they annoyed the companies too badly. A formal RFC that is approved by the IETF would go a long way towards discouraging prosecutors from bringing charges against researchers. ("Members of the jury, how can my client's actions be construed as a crime? He was only following the established procedures laid out by the IETF....")
The problem with drafting an RFC is that not all bugs are created equal, and that usually doesn't get reflected in a standards document. If a popular server application has a local exploit in the installation/registration process, you might want to treat that differently than if the same server application has a remote exploit caused by an inability to handle malformed requests. Why? The first one will affect sites for a brief period of time while the sysadmin installs some software. The second example affects any site running the software, thus having the ability to impact many more people. I'd be much more likely to give the software manufacturer more time to fix a remote exploit...
"Weapons should be hardy rather than decorative" - Miyamoto Musashi
I think that goes for OS's too
I've seen a site well and truly compromised because frickin' Microsoft sat on a bug long after the Blackhat's had an exploit. It only took two days before their entire DMZ was rooted and credit card details stolen, and the stupid thing was, if the site had known that there was a problem they could have worked around it and avoid the legal mess they got into and are still in.
The only saving grace is that this probably won't happen to them again; they are now an ex-customer of Microsoft's and running Apache instead. True, Apache has its own problems, but at least they give you a chance to prevent any issues arising if you care to do so.
PS. Can I interest anyone in 40 used copies of NT Server? Thought not.
UNIX? They're not even circumcised! Savages!
One might want to push for a seperation between responsible disclosure and responsible discovery.
...
For Microsoft, if you release any information during discovery you're probably labelled as malicious even if the thoughts are hypothetical or hunches.
However, its necessary to allow people to work together on the Internet in some form or else we can't benefit from each other's eyes
- Michael T. Babcock (Yes, I blog)
One more step in the 'Full-Disclosure' is bad camp seems to be trying to get their idea of responsibility standardized so they have some RFCs and STDs to point to in their argument. Yes, one should make a reasonable attempt at contacting a vendor, and yes it would be nice if every vendor was so helpful as to 'work with the Reporter' in solving the vulnerability. This doesnt work in practice hardly ever. This whole document is merely an echo of Microsoft's and @Stake's recent push towards limited disclosure and the occulation of vulnerabilities (see no evil). This concept is irresponsible and lazy. Just because I happen to be the first person to report a bug doesnt mean im the first to find it, nor does it mean that there are other people out there who are not actively exploiting it. It is my duty to disclose this information to the WHOLE community in as timely a fashion as possible so that the people who will be affected by this can find a work around or an alternative solution until a patch is issued. This RFC as it stands is much too pro-vendor and would do nothing but harm the security industry were it ever to be widely adopted as a working standard.
--Ks9
Why is the finder of a flaw automatically labeled as the bad guy, and given this list of things to do after the fact? We have completely lost touch with reality here. If a finder releases an exploit or details he/she is considered the faulty party. What about the vender who made the software? I, in no way shape or form, work for that vendor. In the case of closed source, they created the software, they market the software, and they control every aspect of the software. They made a conscience effort to get the software out the door ASAP to make a jump on the competition. In the process they overlooked security, did not test the product fully, and did not care less about you, the end user who found this flaw. Now they want you to work with them and not inform others that are acting as Guinea pigs too? The only reason MS and other large vendors are even considering security now is because of the general public getting wind of it from main stream news media. For me, it depends on the specific vendor for what action to take. MS is not my buddy or friend, and not one I'd care to help for free. They charge per call for general phone support, if they want my support, they can call my 800 number with thier major credit card and pay me, if it turns out not to be a flaw, I'll refund the payment. They have more then enough money to hire thousands of programmers. To them, security is a PR issue and a non-revenue generator.
Bad boys rape our young girls but Violet gives willingly.
The DMCA was written under the guise of "Copyright protection". Copyright's are inherently consumer unfriendly. The purpose of copyright is to LIMIT the things that can be done by the consumer. While certain portions of copyright make sense to ensure commercial viability, others are strictly profit maximizing items. (Remember copyright is the club used to keep CD prices high.)
The original concept of the DMCA was to provide certain additional protections in order to ENCOURAGE the distribution of DIGITAL FORMATS for MEDIA. Using the DMCA to protect software is simply WRONG. Software has always been digital and doesn't suddenly need new and wonderful protections.
The rather spurious argument used to extend DMCA protection into software is that the software is being used to "enforce" provisions in the DMCA so any attempt to circumvent those enforcement mechanisms MUST be a violation of the DMCA. (Realizing of course that using the DMCA to prosecute DeCSS should be non-sensical then. The program allows the exercising of GRANTED RIGHTS, namely viewing, to a LEGAL PURCHASER of the DMCA protected content.)
I guess we're lucky enough to have a country full of lawyers who are more than happy to explain to us why logic isn't the proper thing to use when attempting to interpret the law.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
"We strongly encourage folks to report such problems to our private security mailing list first, before disclosing them in a public forum."
Let's not bash Microsoft too much, if Apache is doing the same thing.