[22201] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Can we afford full disclosure of security holes?

daemon@ATHENA.MIT.EDU (antirez)
Fri Aug 10 20:39:07 2001

Date: Fri, 10 Aug 2001 21:32:23 +0200
From: antirez <antirez@invece.org>
To: "Richard M. Smith" <rms@privacyfoundation.org>
Cc: "BUGTRAQ@SECURITYFOCUS. COM" <BUGTRAQ@securityfocus.com>
Message-ID: <20010810213223.O1176@blu>
Reply-To: antirez <antirez@invece.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00b001c121c0$a1161160$0f01a8c0@tiac.net>; from rms@privacyfoundation.org on Fri, Aug 10, 2001 at 02:39:06PM -0400

On Fri, Aug 10, 2001 at 02:39:06PM -0400, Richard M. Smith wrote:
> This $20 million figure begs the question was it really 
> necessary for eEye Digital Security to release full details 
> of the IIS buffer overflow that made the Code Red I and II worms 
> possible?  I think the answer is clearly no.

The 'no' answer is clear only for you (and few additional people).

1) The next time the code red authors may be the same guys
   that discovered the vulnerability, so your no-disclosure policy
   fails anyway, while it creates the condition to make the next worm
   more aggressive, see the next points.
2) Full disclosure provide to the comunity a lot of information
   and expirience to make better protecion, more secure code
   and security culture around the world. Also create the 'case'
   and the customers will think that maybe that vendor does not
   provide very secure code. This should stimulate the vendor
   to write better code.
3) The lacks of full disclosure and proof of concepts exploit
   helps to create an unsane security feeling about the actual
   software, sysadmin will probably be less responsive upgrading
   they systems so when we reach the point 1) the result is very
   catastrophic.
4) A motivated attacker can anyway obtain information
   about the vulnerability examining the patch in the case of
   opensource software (or the differences between the last and the current
   version), so this (dont) works only for proprietary software,
   without to consider that it is anyway possible to guess
   informations about the vulnerability with two different
   binaries (one patched the second vulnerable).

regards,
antirez

-- 
Salvatore Sanfilippo <antirez@invece.org>
http://www.kyuzz.org/antirez
finger antirez@tella.alicom.com for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF

home help back first fref pref prev next nref lref last post