Bugtraq mailing list archives
Re: [HERT] Advisory #002 Buffer overflow in lsof
From: peterw () CLARK NET (Peter W)
Date: Fri, 19 Feb 1999 17:58:00 -0500
On Thu, 18 Feb 1999, Gene Spafford wrote:
If there is a problem that is not known and not under attack,
How do you know that noone else has found or is using the exploit?
notifying the vendor and waiting for a valid fix to appear is not going to result in anyone being hurt.
Surely a responsible person would not simply wait until the fix is released; even under your rules of etiquette it only makes sense to wait a "reasonable" amount of time.
Posting an exploit widely for a previously unknown problem suddenly opens up all the current users to attack.
For proprietary software that cannot be disabled or replaced with an equivalent piece of code, yes, probably. For software you have the source code for, or "commodity" applications, or non-critical applications, immediate disclosure might help. What if some Internet streaming media server you used had a bug that could compromise a machine? Would you rather know about it so you could save your tail (apologizing to inconvenienced users, of course), or sit on that timebomb and hope the vendor ships a new binary before someone else finds the problem? In *this* instance, it seems that Vic Abell responded quickly, and I'd tend to agree that HERT reacted poorly to their "find" -- although in fairness while they announced a bug, apparently they did not publish exploit code for the script kiddies.** Heck, if they know there's a buffer overflow and they have the source, would it kill the HERT folks to write their own patch? That's the real crime here: if you have the source and are code-literate, why don't you provide a fix? Give something back, for crying out loud! But your sweeping generalizations about what responsible people should do is ill-conceived and smacks of someone coming to knee-jerk defense of a local friend and colleague. -Peter, who guesses Spaf will never autograph his copy of PU&IS now ;-) ** which could bring us into the nasty rootshell/SSH circle -- how do you *know* the hole is real if you don't have the exploit code or a patch? Is Big Brother watching you? Intel is planning on it. With Pentium III, there won't be any online privacy. Act now. http://www.privacy.org/bigbrotherinside/
Current thread:
- Tetrix 1.13.16 is Vulnerable, (continued)
- Tetrix 1.13.16 is Vulnerable Steven Hodges (Feb 17)
- Re: Tetrix 1.13.16 is Vulnerable Pavel Machek (Feb 19)
- ADMsnmp SNMP Audit scanner root (Feb 17)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Gene Spafford (Feb 18)
- Re: [HERT] Advisory #002 Buffer overflow in lsof Theo de Raadt (Feb 18)
- 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)