Re: list policy (Re: Truly scary SSL 3.0 vuln to be revealed soon:)

[Kurt Seifried <kseifried () redhat com>]

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

Attachment: signature.asc
Description: OpenPGP digital signature