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

[ejsteven () CS MILLERSV EDU (Eric Stevens)]

It is my understanding that one of the primary reasons that BugTraq exists
is so that when someone discovers these bugs, they can utilize the vast
resources of the collective bugtraq minds.  Perhaps the poster needs a
solution to this as quickly as possible.  This can easily be expediated if
someone on the list has already found and dealt with the problem.  I agree
that this can provide code kiddies with easy hacks, but if you're in a vital
situation that requires an immediate solution, this may well be the best way
of taking care of that problem.  I think that some discretion should be
used, however.  If there is a problem with your software that does not
require an immediate fix, and you have not yet tried to report it to the
vendor, I believe that you're jumping the gun and unnecessarily putting
others at risk.  Situations like that are cases of arrogance; someone wants
credit for discovering someone else's mistake.

> That some vendors miss problems, or that software in widespread legacy use
is
> suddenly found to be vulnerable to a flaw is still not a reason to widely
> publish a description of a potential attack before the vendor is notified.
>
> Yes, some software could be written better.  Yes, some vendors may do a
poor
> job of responding to reports.
>
> Still, posting attacks or vulnerabilities that are in not in general
> knowledge and are not being actively exploited and *before* the vendor has
> been given a chance to respond is not being part of the solution.   It is
> arrogance or showing off.
>
> People who really want to improve security find ways to avoid hurting
victims
> and increase protection.   If there is a problem that is not known and not
> under attack, notifying the vendor and waiting for a valid fix to appear is
> not going to result in anyone being hurt.   Posting an exploit widely for a
> previously unknown problem suddenly opens up all the current users to
attack.
> That there is (perhaps) a problem in assurance does not forgive this
problem.
> Two wrongs do not make a right.