| 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
| ||
|
Date: Sat, 13 Jan 2007 08:26:04 -0500 From: "Michael Scheidell" <scheidell@...nap.net> To: <smcalearney@....com>, <bugtraq@...urityfocus.com> Subject: RE: seeking comments on disclosure articles > -----Original Message----- > From: smcalearney@....com [mailto:smcalearney@....com] > Sent: Friday, January 12, 2007 9:08 AM > To: bugtraq@...urityfocus.com > Subject: seeking comments on disclosure articles > > > Vulnerability Disclosure: Where Do You Stand? I follow the RFP philosophy. Do a good gob verifying the problem, attempt to contact the vendor, ask them to respond in 5 days (not fix it in 5 days, respond) and if they don't, publish it. If I found it, someone else can. If a vendor then fixes it without coordinating a release, or does not give credit to the security researcher, then I say modify the next report to that vendor and tell them you are going to disclose in 5 days due to their not following the rules. I always put this at the top of the initial report to vendor: This advisory is being provided to you under the policy documented at http://www.wiretrip.net/rfp/policy.html. You are encouraged to read this policy; however, in the interim, you have approximately 5 days to respond to this initial email. This policy encourages open communication, and I look forward to working with you on resolving the problem detailed below. (Shawna, drop me a line and I can give you examples of major security companies that had problems with their own products, and not only did they gloss over the problem, but pretended they could not reproduce it, fixed it, didn't give the researcher credit, and have never sent a fixed copy for the researcher to verify) I don't think that undocumented, unsubstantiated claims do anyone any good. I don't think a security researcher should disclose a vulnerability without giving the vendor a chance to respond. If the vendor follow 'the rules' then further cooperation is encouraged. If a vendor pretends the problem will go away, then I say they don't deserve the warning. I can also think of another vendor of a VPN product that had huge gaping security holes (and the recommended installation straddled the firewall!). I was talked out of disclosure and found out that not only did they never fix the problem, but shortly after they were bought by another company. I don't know if the holes were ever fixed. At least one year later and that other company has not come out with a VPN. No, I think that if a vulnerability exists and isn't fixed, it should be disclosed. Hiding the problem doesn't help. Not disclosing vulnerabilities from vendors who refuse to fix their systems doesn't help. Bottom line: Our company policy, and first choice is to work with the vendor on a fix and a coordinated release of information. If that doesn't work, then public disclosure may be the only way to force them to take some responsibility for their products. http://www.secnap.com/aboutus.php?pg=4 -- Michael Scheidell, CTO SECNAP Network Security Corporation Web based Security and Privacy training: http://www.secnap.com/training ----------------------------------------------------------------- This email has been scanned and certified safe by SpammerTrap(tm) For Information please see http://www.spammertrap.com
Powered by blists - more mailing lists