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."
Its fair that there has been some disagreement between parties, but the current state allows corporations to brand anyone who discloses information responsibly (after appropriately informing the company of a vunerability) as a blackhat hacker and the corporation as a wounded party. They don't care to mention that their vunerability has resulted in countless manhours of sys admin time to correct the fault, deal with the Nimda/Code Red of the week and apply patches - and the corporations often maintain that they should be allowed to keep the information secret from responsible sys admins well after script kiddies are trading the exploit.
Having a standard document will allow mature parties to avoid being branded crackers if they can follow a published disclosure protocol.
You shank my Jengaship!
a day or 2 ago, i started thinking about the DMCA and how those who support it defend it...
usually, they say something like "its to prevent hackers from learning about and exploiting the weaknesses before we have time to fix them" or some similar reason. fair enough, this is valid; i can see how this would be a good thing for preventing software piracy and that sort of thing.
But, when it comes to security and vulnerability to attack, don't I have a right to know? Did I waive that right in an EULA? I'm pretty sure that if this happened with any other kind of product, the government would swoop down and set things right.
Think about it. What if ford had kept the firestone recall under wraps (this "vulnerability" can "crash" the "application" and we don't want hackers/competitiors to exploit it). Yeah- good plan... But I'm the one riding in it! This situation sounds pretty ridiculous when its a "real world" product and not software.
Has anyone else come to this conclusion or know how consumer protection got written out of the DMCA? I'm scratching my head here.
Somewhere on this page I have hidden my signature.
This document is no more than a formalization of @Stake and Microsoft's desire to see the public disclosure that takes place on Security Focus and Cert come to a grinding halt. In their process, the community isn't informed of a the hole/vulnerability until after there's a fix.
I feel that this gives the companies no motivation to fix the hole. I would instead suggest that when the "reporter" informs the company, The company receives a grace period of 30 days to work on a fix after such a point the "reporter" could come forward, and release the hole publically if he/she/it felt that the company wasn't making a good faith effort to fix the problem. Of course this whole process is null and void if the program is open source/free software and the "reporter" releases a patch for the flaw at the same time the "reporter" releases the flaw.
Ponder that my friends.
There are, of course, people who discover vulnerabilities and immediately publish all the details without notifying the vendor, but an RFC is hardly going to stop.
All the same, guidelines are nice. I'm a little skeptical of vendors sticking to the suggestions. To many SHOULDs and MAYs.
To recap, the proposed RFC suggests 7 stages in fixing a vulnerability:
1. Latent flaw. The flaw exists undiscovered.
2. Discovery. Somebody finds the flaw (the 'Reporter').
3. Notification. The Reporter notifies the Vendor.
4. Validation. The vendor verifies the flaw.
5. Resolution. The vendor fixes the flaw.
6. Release. The vendor publishes the flaw.
7. Follow-up. Analysis of the resolution.
What a nice world this would be.
It usually works like that right up until step 5. Here's what really happens:
5. Denial. The vendor denies the flaw really exists, setting his best PR guys on the job.
6. Demonstration. The Reporter creates exploit code to prove to the vendor that not only does it exist, but it is serious and should be fixed.
7. Diversion. The Vendor changes the subject by publicly attacking the Reporter for creating the demonstration, labeling it a "Hacker Tool".
8. Publication. Third party bug tracking systems and security entities make knowledge of the vulnerability widespread to try to scare the Vendor's customers.
9. Fix. The Vendor repairs the vulnerability, while still denying that it has any real significance.
10. Release. The Vendor shuffles the release into a service pack or update, and puts it on his web site.
This process seems to be heavily biased towards the vendor and does not seem to offer very much to the community at large. A vendor not interested in exposing vulnerabilities could easily exploit this process.
/reported/ discovery.
Simply setting up the recommended email address and generating an auto-reply (or the equivalent with form letters and an assistant) to all reports would acknowledge all claims. This auto-reply could immediately include a request for extension. Delay the auto-reply from 4-7 days, put snapshots of similar keyword searches from the internal knowledgebase, and you have a suitable claim for an extension.
Any disclosure of the flaw before the extension and the vendor can quite happily say that they are following the process and the reporter is not. Meanwhile the vendor themself has no reason, what-so-ever to follow the remaining sections of the process, then can simply allow all periods to lapse and proceed on their own accord. This allows the reporter to be labelled in bad faith, whereas the vendor can artificially appear to act in good faith.
Not following this best practice would furthermore not generate any additional bad publicity for the offending company. Vendors operating in bad faith will already have a negative image. Vendors operating in good faith will have an extra overhead that they may not be able to support if they follow this process.
It additionally appears vendor biased because it does not offer any benefit to the security community, or the user community at large. Prevention of exploits does not appear as a goal of this process. Nor does protection from exploitation of flaws. Unless of course we make the unreasonable assumption that exploits do no appear until over 30 days past the point of
I know it's a strange term, but generally a whitehat finding a bug doesn't do it all alone. They do it with the help of others. So if I'm looking at a bit of code and see something that looks poorly coded, am I still permitted to go post on a public mailing list "hey, this kinda looks broken, someone wanna take a look at it?" or is that against the draft (and as such I'll be labeled as "malicious"). If I happen to be looking at a config file or a protocol specification and notice that the design seems to have an inherent security flaw (trusting user data for example), am I permitted to talk about it publically, or as a "reporter" am I required to go look at every product that implements that standard and report my findings only to the vendor of those products. I suppose all these questions will get sorted out in the wash eventually.
How we know is more important than what we know.
I am sure that you are receiving dozens of comments on this draft, so I will try to keep mine brief. I am a security technician and sysadmin for a large nonprofit research organization. In your draft's terms I believe I represent a "User" more than a "Reporter" -- though a user with security-specific experience.
It seems to me that your draft undervalues the powers of users to protect themselves independent of the actions of vendors. Users are not entirely reliant upon the vendors of the software they presently use to protect themselves, and they can make use of published security information even if a vendor does not choose to acknowledge or proceed responsibly with the knowledge of a vulnerability. Moreover, they have a need for this information outside of its use in getting patches for existing software.
Most software users are not obligate users of particular pieces of software. They choose among competing software products (or even system designs), and make use of published information about these products in making their choices. They may choose to migrate from an installed software product to a competing one on the basis of published security concerns.
Because users need security disclosure to make informed decisions about the costs and benefits of pieces of software, they have an interest in a fuller and more analytical disclosure than vendors may desire. Large vendors may prefer users who have already purchased their products not to later question this purchase. They may resist the idea that a /pattern/ of vulnerabilities or poor practices exist in their software.
And for a vendor to quietly roll security patches into an "upgrade" may
help the user to avoid being cracked, but does not help him or her make
responsible decisions about future purchases.
Security researchers, it seems to me, have an ethical obligation not to aid criminals in attacking users. However, they (you) do not have an obligation to keep vendors from losing business, or to allow vendors to keep users in the dark regarding the comparative security strengths of software products. In many cases, users would be better served by being advised when the software they are using is poorly designed, has a history of vulnerabilities, and is likely to remain vulnerable to new sorts of attack -- rather than merely being told to wait for a patch, or not told anything independently at all.