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: <382BC0C28F397F4785E7414B8279F5271B533E@n2-atl-exch.it.n2bb.com> From: ARouse at n2bb.com (Alan Rouse) Subject: it's all about timing Timothy J.Miller [cerebus@...kheads.org] wrote: > I can't agree. In my day job I maintain systems for a defense agency, > and I *have* to know what my exposures are *at all times*, whether a fix > exists or not, since lives can be dependent (directly or indirectly) on > the availability and integrity of my systems. > > Without this information, I can't mitigate my risk. Leaving *my* risk > in the hands of a vendor-- who has a vested interest in *not* letting me > know-- is wrong. If one person can discover a vulnerability, so can another person. When you discover a previously unpublished vulnerability you should assume that either (1) someone else has also discovered it and is keeping it secret for future use; or (2) someone like that will discover it soon. The vendor must not be permitted to sweep it under the rug, or to put it on the back burner. If they do, a day of reckoning will come to them and to all their customers. Some naive people think the visible blackhat hackers are the real enemy. These people break into sites, deface them, maybe even steal some files or install Trojans... IMO that's NOT the main problem. Maybe that kind of thing is not nice, not legal, maybe it causes monetary losses to victims... but it's not nearly the worst problem. A major terrorist organization or enemy country would do far worse. Undoubtedly there are others out there, with greater resources, and much more serious in their intent to do harm. They are busy discovering vulnerabilities, and building an inventory of individual exploits and compound exploits which would make everything we've seen to date look like child's play. In this kind of world, the public needs to know immediately of the vulnerability. We need to be able to determine unambiguously whether we are vulnerable. We need to be able to implement countermeasures, and then we need to be able to test those countermeasures. This means we need a proof of concept exploit, and we need it immediately. And we need source code for that exploit so we can verify that this code itself is not an enemy. Now, that proof of concept exploit should not do any actual damage. And it should not be easily converted into a damaging tool by pseudo-technical script-kiddie types. That is where ethics and good judgment are required. There will probably be differing opinions on what should be released. I lean toward more disclosure rather than less, but the rules of the game must protect the publisher of the vulnerability, because he provides a critical service. We cannot afford to squelch those who expose these problems. Unfortunately some companies have shown themselves to be unwilling to correct vulnerabilities without a threat of harm. I don't know whether that justifies the blackhat vandals. But in the absence of legal recourse (e.g. vendor liability lawsuits) it may be the one thing that forces vendors to close the holes. Publicly disclose the vulnerability immediately, along with recommendations for temporary countermeasures until a fix is available, and provide a way to test those countermeasures. That's about the best we can do IMO. Ok that's my rant. I feel better.
Powered by blists - more mailing lists