| 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: <BAY124-DAV143B6D843A6610F4799D04D9460@phx.gbl> Date: Sun, 6 May 2007 11:26:50 -0700 From: "Morning Wood" <se_cur_ity@...mail.com> To: "shadown" <shadown@...il.com>, <dailydave@...ts.immunitysec.com>, <full-disclosure@...ts.grok.org.uk>, <bugtraq@...urityfocus.com> Subject: Re: [Full-disclosure] Vulnerabilities Hashes DB needed > As I do believe in responsible disclosure, I don't agree with 'giving up > and > launchin 0days' so that vendors eat their s**t, the following is what I > think is the best solution for it. > > Solution: > ------------- Once I developed this, vendors were typicaly fast to respond... http://www.exploitlabs.com/disclosure-policy.html This link is sent upon first contact to the vendor with PoC. Further you should date your PoC and research notes, another good tactic to take is to place your advisory on a webserver, accessable to the vendor but not the public. This also helps establish your timeline so a vendor cannot claim it was fixed "on foobar date" and you get no credit. With over 50 security advisories to date, I have not had the issue you are having. Some disclosure asset links http://www.wiretrip.net/rfp/txt/ietf-draft.txt http://www.oisafety.org/ http://www.dhs.gov/xlibrary/assets/vdwgreport.pdf Some stories on disclosure and credit http://blogs.zdnet.com/Ou/?p=465 http://blogs.securiteam.com/index.php/archives/133 http://www.theregister.co.uk/2001/11/14/ms_security_framework_is_another/ hope this helps, Donnie Werner http://www.exploitlabs.com http://www.zone-h.org
Powered by blists - more mailing lists