|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: Final position RE: [CVEPRI] Handling new vulnerabilities disc overed by Steve Christey
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hahahaha... This thread is the funniest thing that has come through my inbox in quite some time. Funnier than the hamster dance. Funnier than George Lucas in Love. Funnier, even, than the time that a competitor (who shall remain nameless) sent me an unsolicited message offering their anti-virus product "at a special price". Steve's original question was whether or not there is a problem with his discovering, assigning candidate numbers for, and releasing security announcements for vulnerabilities. To that original question, I say "of course not." If Steve starts making a habit of releasing vulnerabilities sent to him as his own, people stop sending vulnerabilities for candidate assignment. I just don't see it as a big threat. That being said, the conversation then turned to the issue of the source and motivation of advisory releases in general. Speaking as a member of an organization that includes finding new vulnerabilities as part of its charter, I feel like I should chime in. OF COURSE there is an element of self-promotion involved. Aleph, Marcus, and Russ - bear in mind that not everyone in the industry is as well-established as you are... The only way for many of them to gain that recognition (and some of them certainly may deserve it) is to make their work public. When a security provider (whether it be tools or services) releases an advisory, it tells their customers that they are actively looking for new threats, and taking steps to eliminate them. Marketing? Maybe. When an individual releases an advisory, it tells security providers that they are looking for a job. Marketing? Almost certainly. In all seriousness, though, the advisory also serves other purposes - it keeps software vendors honest in getting quality patches released, and it helps everyone (researchers and vendors alike) find and fix potentially similar problems in other products - and isn't that our ultimate goal? Moving on to the issue of disclosure, I would like to share our policy: As a general rule, we notify vendors of a problem, and wait until there is a patch. If an exploit shows up in the wild and is being actively exploited, we will release the advisory without a patch and hopefully be able to offer suggestions for end users to implement protective measures. I would call this "responsible disclosure", and I feel that most vulnerability research follows this pattern. Problems that show up in a public forum are a slightly different animal. Someone may post to *Bugtraq asking about strange behavior or an apparent problem. It may result in the discovery of a more serious flaw. Work-arounds may be suggested, and patches may be developed, but there will most likely be a delay between the discovery of the problem and a fix being available. This, to me, is life in the world of computer security. When security researchers (either professionals or gifted amateurs) "leak" a vulnerability in this manner, I consider it to be irresponsible. Most people who do any significant amount of research will take the time to verify unusual behavior and contact vendors before making any sort of public announcement. Now, if you want to talk about improving the situation, then let's start by making the process easier for security researchers to work with the vendors in the first place. A quick first step would be for every hardware and software vendor to set up (and I mean today) a "security@*.com" and/or "security-alert@*.com" e-mail box that is assigned to someone in the organization. I have, on several occasions, spent a lot of time scouring newsgroups and war-dialing DID's to find SOMEONE who could address a security flaw in their product. If it's easy to contact a vendor, and they are responsive both to initial queries and to follow-up requests, I feel that most people will be more than happy to work with the engineers involved in producing a patch. PLEASE NOTE: I am not dismissing the responsibility of researchers to provide clear, reproducible reports to the vendor. I think that this is very important and should be reinforced whenever possible. The better the initial report/advisory, the easier it is for the vendor to identify and (hopefully) fix the problem. One step at a time. A journey of a thousand miles... etc, etc, etc. So. That's my take, for what it's worth. Are we saving the world? I don't know, but I hope we're helping to make it a safer place. - - Jim -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1 Comment: Crypto Provided by Network Associates <http://www.nai.com> iQA/AwUBOcv66gDjeqNVcQB5EQIXCwCg/kZzDHWkvb+304ei6D4DJCkrCFwAoNzY q792rWRfonk6KBoW5+WfCevC =UirR -----END PGP SIGNATURE-----
|
||||