bugtraq - RE: seeking comments on disclosure articles

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <B3BCAF4246A8A84983A80DAB50FE7242862824@secnap2.secnap.com>
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