[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALx_OUD8-NzvT4bQXkHJcaxCGd8h3WjmLEkQ=sngciyosmNA9A@mail.gmail.com>
Date: Wed, 29 Oct 2014 14:56:57 -0700
From: Michal Zalewski <lcamtuf@...edump.cx>
To: oss-security <oss-security@...ts.openwall.com>
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 <kseifried@...hat.com> 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
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.
