[22201] in bugtraq
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