[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110403220938.GE9516@openwall.com>
Date: Mon, 4 Apr 2011 02:09:38 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: Closed list
On Sat, Apr 02, 2011 at 06:00:40AM +0200, klondike wrote:
> Will the list provide protection against rubber-hose cryptanalisys?,
No, it won't. Worse, people will also have the temptation to make use
of the information at their other jobs, etc. For example, a security
contact for a distro might not only prepare updated packages, but also
patch their personal server early... which adds to the risk.
I see no way to deal with this technically, other than by keeping the
number of subscribers relatively low (only those who "need to know") and
by only discussing medium-severity issues on the list (thus high
severity ones will have even more focused distribution).
Arguably, medium-severity issues are not worth rubber-hose cryptanalysis
and are not as tempting to patch, yet their handling may benefit from
some coordination between distro vendors.
> Sometime ago I was taught that the best way to be sure a secret was not
> known was not saying it, so if you, researchers, want to make sure your
> PoC aren't abused do things properly, warn the vendors to upgrade the
> product because of your security finding and avoid providing PoCs until
> enough time has passed for you to be sure everybody has had a chance to
> upgrade.
This makes sense to me. No need to provide vendors with more info than
they need to properly patch the issue and verify the fix. The latter
will sometimes require access to a PoC, though, but I'd prefer such PoCs
to be sent directly to vendors who express interest in testing their
fixes rather than posted to a multi-vendor exploder list.
> Any other solution can be easily flawed since you can't make sure I
> won't buy/kidnap/kidnap relatives of/steal data from etc. on anybody on
> such a private list.
Sure, but it's always a tradeoff, and the risk is there even if you
share a vulnerability report without a PoC.
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
