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
| ||
|
From: fw at deneb.enyo.de (Florian Weimer) Subject: Vulnerability Disclosure Debate gridrun <gridrun@...es.smart-girlies.org> writes: > The security alliance around Microsoft is trying to push its > "reasonable vulnerability disclosure guidelines", which seeks to > prevent security researchers from publishing proof-of-concept code > alltogether, and wants them to make only limited, next to useless, > information about security flaws available to the public. Nice stance, but complete off target. Currently, Microsoft releases the most detailed advisories, in a consistent format, with extensive information about possible workarounds etc. They are pretty close to the optimum you can achieve if you want to avoid to disclose the actual cause of the problem. > In my humble, personal opinion, this step seeks to maximize income of > several large security firms, as they would release any detailed > information only to paying groups of subscribers... This is in fact a problem. But it is not Microsoft-specific at all. The free software camp has adopted the responsible disclosure process while Microsoft still was struggling with significant security issues being reguarly publicized before they could provide countermeasures or even investigate them. If you think that system administrators can live without decent security advisories as soon as they have source code, you are wrong. Most of them lack the skills, knowledge and the time for a source-level investigation. Even with an isolated source code patch (which isn't the norm, sadly), it can still be very difficult to rate the risk for your own organization and its systems. (For example, you might lack the knowledge of the finer points of the protocols involved.) > To me, full disclosure makes perfect sense. Tell people about the > vulnerability as soon as you notice it exists, you'll see > "proof-of-concept" code appearing within days - essentially a proof > that there were other people knowing about the vulnerability already. Non sequitor. Some people are just quick and creative, even without early access to details. > Also, full disclosure, including exploit code, frees you from the > obligation to believe in software vendor advisories and patches - Full disclosure keeps honest vendors honest, but the days of full disclosure are over. Almost never, the initial discoverer of a vulnerability publishes the exploit. For some vulnerabilities, someone else publishes an exploit. But you can't rely on this, you have to establish procedures which assume only a very limited form of disclosure.
Powered by blists - more mailing lists