Hi, I think the introduction of the process makes a lot of sense, however, I feel that the process as it stands presents a problem with regard to dissemination of information.
1. In the proposal, Section 2.3 Timeline: "The Finder and Vendor observe a 30-day grace period beginning with the release of the remedy, during which they provide such details only people and organizations that play a critical role in advancing the security of users, critical infrastructures, and the Internet." a. Who is considered to be part of the exceptional list? Members of OI Safety? ISPs? What about security consultants? b. If this information will be made available to anyone that plays a critical role in advancing the security of users, then how will the list be moderated and controlled? As this process has been proposed by OI Safety, one cannot help but think that these exceptions create an unfair advantage for members of OI Safety. After all, many of the members provide a chargeable vulnerability notification service (or offer a vulnerability assessment product) to their customers - if they are able to offer the information to their customers before the information is issued to the general public, they have an unfair advantage over anyone else that is not privy to the early release of this information. c. What can be done to prevent this problem from occurring? 2. In 7.3.11: "The Vendor and the Finder shall exercise reasonable efforts to avoid providing information in the security advisory that could aid attackers in exploiting the vulnerability." And 7.3.12: "The Security Advisory shall not include proof of concept code or test code that could readily be turned into an exploit, nor detailed technical information such as exact data inputs, buffer offsets, or shell code strategies." While the idea behind these points does make sense in that it will help prevent attacks from 'script kiddies', I think that it can be safely assumed that any attacker with some skills should be able to reverse-engineer a fix and discover the underlying vulnerability that was patched. Once that has been done, it is likely the exploit details will be made publicly available, in some form or another. By not providing this information, smaller security consulting firms and individuals will be unable to utilise or create PoC code to test for these vulnerabilities, without having to go through the 'illegal' process of reverse engineering the patches. Instead, they will have to wait until details become available from the 'underground' community... The net result is that attackers will have a head start and organisation's security will be put at risk! Smaller security consulting firms and individuals may not have the R&D capabilities or budgets that the larger security firms have (such as the members of OI Safety) and thus may rely on the exploit details and PoC code in advisories to help them with their work. In my opinion, there are many smaller security consulting firms and freelance security consultants that do a very good job of helping secure the smaller organisations and home users - something that should not be forgotten. Organisations should not be forced to have to use vulnerability assessment tools or services from the larger security organisations that are privy to this sensitive information or that have the large R&D budgets for 'figuring out' the underlying cause / vectors / details of a vulnerability. In my opinion, the restriction of this kind of information will do more harm to the industry than good. I also feel that the only companies that will benefit from the proposed timeline and the restrictions on 'detailed' information are the OI Safety companies - as they will share detailed information about the vulnerabilities and will have access to the information long before anyone else - giving them a distinct advantage in the security industry. a. Is there a way to provide some form of controlled release of this 'detailed' information? b. Again, who will have access to the information and how will it be controlled? I look forward to hearing your response. Kind regards Byrne Ghavalas _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
