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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ