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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed Apr 13 18:50:36 2005
From: bkfsec at sdf.lonestar.org (bkfsec)
Subject: How to Report a Security Vulnerability to
	Microsoft

Steve Friedl wrote:

>
>My personal resolution: write two advisories. The first one is released
>with the patch, but it doesn't contain a roadmap for how to create an
>exploit. This gives the researcher the credit for the initial discovery.
>
>The second advisory has all the details, and I'd hold it until either some
>time period (90 days?) or until an active exploit was circulating. This
>lets me publish the technical details sooner or later but at least gives
>a head-fake to "caring about the users".
>
>  
>
I think that that's a reasonable position to take.   I don't think that 
it's indefensible at all.  I don't think that we can say that one policy 
applies to all situations, and that was really my point here.  A lot of 
vendors (for their own gain, obviously) want to tie researchers down to 
one policy which is highly tilted in their favor.  That's just not 
realistic.  The researcher should have options in how to handle the 
disclosure, if only for the fact that limiting disclosure is a limit to 
our ability to share information - which is not a good thing.  My point 
is that the the researcher making the disclosure should determine their 
timeline, but with obvious consideration of the vendor and users, but 
that that should be a reasonable approach, and not followed because the 
researcher is forced to follow it.

             -Barry


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ