lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <382BC0C28F397F4785E7414B8279F5271B533E@n2-atl-exch.it.n2bb.com>
From: ARouse at n2bb.com (Alan Rouse)
Subject: it's all about timing

Timothy J.Miller [cerebus@...kheads.org] wrote:
> I can't agree.  In my day job I maintain systems for a defense agency,

> and I *have* to know what my exposures are *at all times*, whether a
fix 
> exists or not, since lives can be dependent (directly or indirectly)
on 
> the availability and integrity of my systems.
> 
> Without this information, I can't mitigate my risk.  Leaving *my* risk

> in the hands of a vendor-- who has a vested interest in *not* letting
me 
> know-- is wrong.

If one person can discover a vulnerability, so can another person.  When
you discover a previously unpublished vulnerability you should assume
that either (1) someone else has also discovered it and is keeping it
secret for future use; or (2) someone like that will discover it soon.
The vendor must not be permitted to sweep it under the rug, or to put it
on the back burner.  If they do, a day of reckoning will come to them
and to all their customers.

Some naive people think the visible blackhat hackers are the real enemy.
These people break into sites, deface them, maybe even steal some files
or install Trojans... IMO that's NOT the main problem.  Maybe that kind
of thing is not nice, not legal, maybe it causes monetary losses to
victims... but it's not nearly the worst problem.  A major terrorist
organization or enemy country would do far worse.  Undoubtedly there are
others out there, with greater resources, and much more serious in their
intent to do harm.  They are busy discovering vulnerabilities, and
building an inventory of individual exploits and compound exploits which
would make everything we've seen to date look like child's play.  

In this kind of world, the public needs to know immediately of the
vulnerability.  We need to be able to determine unambiguously whether we
are vulnerable.  We need to be able to implement countermeasures, and
then we need to be able to test those countermeasures.  This means we
need a proof of concept exploit, and we need it immediately.  And we
need source code for that exploit so we can verify that this code itself
is not an enemy.

Now, that proof of concept exploit should not do any actual damage.  And
it should not be easily converted into a damaging tool by
pseudo-technical script-kiddie types.  That is where ethics and good
judgment are required.  There will probably be differing opinions on
what should be released. I lean toward more disclosure rather than less,
but the rules of the game must protect the publisher of the
vulnerability, because he provides a critical service.  We cannot afford
to squelch those who expose these problems.

Unfortunately some companies have shown themselves to be unwilling to
correct vulnerabilities without a threat of harm.  I don't know whether
that justifies the blackhat vandals.  But in the absence of legal
recourse (e.g. vendor liability lawsuits) it may be the one thing that
forces vendors to close the holes.

Publicly disclose the vulnerability immediately, along with
recommendations for temporary countermeasures until a fix is available,
and provide a way to test those countermeasures.  That's about the best
we can do IMO.

Ok that's my rant.  I feel better.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ