lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <200208022144.RAA29377@linus.mitre.org> From: coley at linus.mitre.org (Steven M. Christey) Subject: Re: it\'s all about timing choose.a.username@...hmail.com said: >It is very unclear as to what it is that you are really after. Who are >these people "Vulnerability researchers", who's label is this? It's an RFPolicy-ism. Alternate terms are "reporter" (which covers "bug hunters" and "people from the press") and "notifier" (which is probably more accurate than "researcher," because the notifier might not be the person who discovered the issue). I'm leaning towards "notifier." >Are thes professionals now not adhereing to some suitable reporting >method where they do in fact alert the vendor in private, work with >that vendor in private, and then release the advisory? Is this not the >case already? Based on an informal study I've done of about 350 researcher reports from early 2002, approximately 50% of the vulnerabilities were released without notifying the vendor, and about 20% of those reports included full exploit code. (NOTE: the data is presently incomplete; but I hope to publish a full report in the future). But even in the case where the vendor is notified ahead of time, one needs only to look at the recent HP/SnoSoft situation to see that there are different opinions on how disclosure should happen. Going a little further back, the ISS/Apache situation also demonstrated a variety in how professionals handle vulnerability reporting. We may agree on the general notion of "give vendors some warning," but when you get down to the nitty gritty details - like *how much* warning, and how much effort the researcher should make, and how the vendors should respond - suddenly you realize that there's a lot of variety. You speak of "harnessing" vulnerability researchers. A number of people have said that the current RVDP draft asks too much of researchers, including Georgi Guninski and Rain Forest Puppy (and some vendors). That feedback will be taken into account in the next version. In the meantime, the current RVDP draft already has a number of suggestions for vendors: 3.3.1 Vendor Responsibilities 1) The Vendor MUST make it as easy as possible for Reporters, Coordinators, Customers, and the Security Community to notify the Vendor of vulnerabilities. as well as: 3) The Vendor SHOULD ensure that its staff knows how to recognize a reported security issue and direct it to the Security Response Capability. This recommendation applies to staff who provide support online, over the telephone, in person, or through some other means by which reporters may interact with the Vendor. as well as: 6) The Vendor MUST provide a facility for individuals or organizations who are not Customers to report vulnerabilities. The Vendor SHOULD NOT require (1) an active technical support number, (2) telephone access that is not toll-free, or (3) user registration for a web site or other facility that would be used for reporting. If more vendors follow the recommendations in the current draft, it will be easier for people to report vulnerabilities to them, which I think is a good thing. >Or do you mean the one-off vulnerabilty report, the one that some >individiual stumbles upon and sends it off to the lists. If the one-off person knows about security-related mailing lists, then hopefully they'll know something of disclosure issues. >Are you trying to harness them? Do you think some standard setout on >what do do with the reporting is going to trickle down to the >individual man in the street and he's going to (a) know about it (b) >be bothered to follow the method if he did. If there is enough awareness of disclosure issues in the IT community, then hopefully this won't happen as much. However, as you say, there will always be people who won't follow the disclosure guidelines. You may be surprised to learn that the RVDP draft specifically tells vendors that they should be prepared for such a situation: 3.3.1 Vendor Responsibilities 7) The Vendor SHOULD recognize that inexperienced or malicious reporters may not use proper notification, and define its own procedures for handling such cases. I've mentioned at least 4 vendor requirements from the current draft, which would make the notification process easier for researchers. >Is there then a third set out there that needs this guidence everyone >is hollering about? I think so, and that's the people who are somewhere in between - maybe they're not professionals, but maybe they like to do research for fun, to analyze the software they use themselves, to build a resume, whatever (and before someone misinterprets what I just said, I personally don't think that there's anything wrong with doing research for resume-building). Sometimes, it seems that researchers start out by releasing advisories without notifying the vendor, then as they gain experience, they work with the vendor more and more. But I don't have any hard numbers to back that up. Indeed, the whole area of disclosure is woefully short of hard numbers. - Steve
Powered by blists - more mailing lists