[9704] in bugtraq
Re: [HERT] Advisory #002 Buffer overflow in lsof
daemon@ATHENA.MIT.EDU (Fred W. Noltie Jr.)
Sun Feb 21 21:14:49 1999
Date: Fri, 19 Feb 1999 15:25:58 -0600
Reply-To: "Fred W. Noltie Jr." <criterion-consulting@USINTERNET.COM>
From: "Fred W. Noltie Jr." <criterion-consulting@USINTERNET.COM>
X-To: route@RESENTMENT.INFONEXUS.COM
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <19990219004617.24816.qmail@resentment.infonexus.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
# -----Original Message-----
# From: Bugtraq List [mailto:BUGTRAQ@NETSPACE.ORG]On Behalf Of
# route@RESENTMENT.INFONEXUS.COM
# Sent: Thursday, February 18, 1999 6:46 PM
# To: BUGTRAQ@NETSPACE.ORG
# Subject: Re: [HERT] Advisory #002 Buffer overflow in lsof
#
#
# [Gene Spafford wrote]
# |
# | People who publish bugs/exploits that are not being actively
exploited
# | *before* giving the vendor a chance to fix the flaws are clearly
# | grandstanding. They're part of the problem -- not the solution.
# |
#
# Who is to say the vulnerability in question was NOT being
exploited
# prior to release? Odds are it was. Bugtraq is a full-diclosure
list.
# The `problem` as you succinctly put it is in *non-disclosure*.
While
# it is still questionable whether or not the original posters
# found the bug
# themselves (the advisory lacked any technical detail) calling
# them part of
# the problem is a misfire of your disdain (attacking them on
# the content
# of the advisory --or lack thereof-- is a much better call).
# The problem,
# in this case, would be the malevolent individual(s) breaking
into your
# machine exploiting this bug (before or after it was disclosed).
#
# Don't shoot the messenger.
I have to disagree with this. The "messenger" _fails_ if he announces
the problem to the crackers of the world before giving the vendor a
chance to prepare a fix. The "messenger" has then shown that he is
less interested in getting security problems solved than he is in
revealing them. I don't think this says much about our "messenger"'s
goodwill.
We may not know if a hole was being exploited before an announcement
of it, but we certainly know that crackers will have much more success
with it if the vendor isn't given a chance to fix it first.
Of course the bad code is the real problem, but failing to act in the
best interest of the _users_ (you know, the folks who suffer when a
hole is announced without giving a vendor a chance to fix it) is a
problem too.
Giving the vendor an opportunity to fix a problem before announcing it
is _not_ in conflict with the idea of full disclosure.
I'm not saying you have to wait 6 months for action by a vendor, but
failing to give them a chance is hardly The Right Thing To Do.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0 for non-commercial use <http://www.pgp.com>
iQA/AwUBNs3W4D6xU7QBzFqYEQJTlQCbB5JVyEHE5/lEAPP0FUsvTjiT9wkAn2sb
tSPuikaFQBjQtmmWbAUxCAM0
=wK/j
-----END PGP SIGNATURE-----
