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:
- Re: [HERT] Advisory #002 Buffer overflow in lsof, (continued)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Gene Spafford (Feb 18)
- IE0199.exe uninstaller David Brumley (Feb 19)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Weld Pond (Feb 19)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Valdis.Kletnieks () VT EDU (Feb 19)
- Plaintext Password in Tractive's Remote Manager Software Trevor Gryffyn (Feb 19)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Peter W (Feb 19)
- Re: [HERT] Advisory #002 Buffer overflow in lsof John DiMarco (Feb 19)
- Re: [HERT] Advisory #002 Buffer overflow in lsof brian j pardy (Feb 19)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Greg Woods (Feb 19)
- Re: [HERT] Advisory #002 Buffer overflow in lsof route () RESENTMENT INFONEXUS COM (Feb 18)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Fred W. Noltie Jr. (Feb 19)
- Call to politeness (Re: [HERT] Advisory #002 Buffer overflow in alecm (Feb 19)
- pine 4.10 patches (similar to 4.05) GvS (Feb 20)
- Re: [HERT] Advisory #002 Buffer overflow in lsof M.C.Mar (Feb 20)
- full disclosure and vendor education Antonomasia (Feb 20)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Lamont Granquist (Feb 18)
- Win98 Buffer Overflow (File attached) Scott (Feb 14)