Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 29 Oct 2014 14:56:57 -0700
From: Michal Zalewski <>
To: oss-security <>
Subject: Re: list policy (Re: Truly scary SSL 3.0 vuln to be
 revealed soon:)

Or just require an accompanying explanation. But FD is as much of a
watering hole and has a long history of fake exploits being posted...
I think we could survive.

(BUGTRAQ, too, although that list seems to be in a pretty bad shape
these days and perhaps its days are numbered).

On Tue, Oct 28, 2014 at 6:26 PM, Kurt Seifried <> wrote:
> On 28/10/14 06:48 PM, Alexander Cherepanov wrote:
>> On 2014-10-29 02:47, Kurt Seifried wrote:
>>> On 28/10/14 07:47 AM, Alexander Cherepanov wrote:
>>>> On 2014-10-15 12:30, Solar Designer wrote:
>>>>> - Please don't send fully working exploits (but testcases that exercise
>>>>> the flaw are welcome)
>>>>> FWIW, I've always been tempted to remove the latter guideline,
>>>> Then perhaps just remove it? It always seemed to me a strange
>>>> restriction. Other guidelines are either technical in nature or they are
>>>> intended to reduce the amount of noise. This restriction seems to be
>>>> neither.
>>>> Of you can replace it with something like this:
>>>> - Please only send fully working exploits which themselves are
>>>> open-source.
>>> Will someone/people vet the exploits to make sure they are not trojan
>>> horses/self harming (e.g. the rm -rf * embedded in it somewhere?).
>>> Strikes me as a heck of a watering hole attack potentially (and yes,
>>> list members should know better, but ... yeah).
>> This is an interesting question but how "fully working exploits" differ
>> from "testcases that exercise the flaw" in this regard?
> For example using something like metasploit the code would (in theory)
> be more radable and anything hidden/obfuscated would stick out. My vote
> would be to require well written nmap scripts or metasploit modules that
> don't contain obfuscated code/etc. This would also make getting them to
> work simpler (no use of weird one off CPAN modules or specific versions
> of some obscure python thing, etc.).
> --
> Kurt Seifried -- Red Hat -- Product Security -- Cloud
> PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ