Bugtraq mailing list archives

Re: [HERT] Advisory #002 Buffer overflow in lsof


From: criterion-consulting () USINTERNET COM (Fred W. Noltie Jr.)
Date: Fri, 19 Feb 1999 15:25:58 -0600


-----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-----



Current thread: