oss-sec mailing list archives
Re: list policy (Re: Truly scary SSL 3.0 vuln to be revealed soon:)
From: Michal Zalewski <lcamtuf () coredump cx>
Date: Wed, 29 Oct 2014 14:56:57 -0700
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 () redhat 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
Current thread:
- Re: Truly scary SSL 3.0 vuln to be revealed soon:, (continued)
- Re: Truly scary SSL 3.0 vuln to be revealed soon: Reed Loden (Oct 14)
- Re: Truly scary SSL 3.0 vuln to be revealed soon: Hanno Böck (Oct 14)
- RE: Truly scary SSL 3.0 vuln to be revealed soon: Sona Sarmadi (Oct 14)
- Re: Truly scary SSL 3.0 vuln to be revealed soon: Walter Parker (Oct 14)
- Re: Truly scary SSL 3.0 vuln to be revealed soon: Brandon Whaley (Oct 15)
- list policy (Re: Truly scary SSL 3.0 vuln to be revealed soon:) Solar Designer (Oct 15)
- Re: list policy (Re: Truly scary SSL 3.0 vuln to be revealed soon:) Alexander Cherepanov (Oct 28)
- Re: list policy (Re: Truly scary SSL 3.0 vuln to be revealed soon:) Kurt Seifried (Oct 28)
- Re: list policy (Re: Truly scary SSL 3.0 vuln to be revealed soon:) Alexander Cherepanov (Oct 28)
- Re: list policy (Re: Truly scary SSL 3.0 vuln to be revealed soon:) Kurt Seifried (Oct 28)
- Re: list policy (Re: Truly scary SSL 3.0 vuln to be revealed soon:) Michal Zalewski (Oct 29)
- Re: list policy (Re: Truly scary SSL 3.0 vuln to be revealed soon:) Dave Horsfall (Oct 29)
- Re: list policy (Re: Truly scary SSL 3.0 vuln to be revealed soon:) Michal Zalewski (Oct 29)
- RE: Truly scary SSL 3.0 vuln to be revealed soon: Sona Sarmadi (Oct 14)
- Re: list policy (Re: Truly scary SSL 3.0 vuln to be revealed soon:) Solar Designer (Nov 03)
- Re: SSL POODLE (Truly scary SSL 3.0 vuln) gremlin (Oct 14)
- Re: SSL POODLE (Truly scary SSL 3.0 vuln) Krassimir Tzvetanov (Oct 14)
- Re: SSL POODLE Florian Weimer (Oct 15)
- Re: SSL POODLE Hanno Böck (Oct 15)
- Re: Truly scary SSL 3.0 vuln to be revealed soon: Reed Loden (Oct 14)
- RE: Truly scary SSL 3.0 vuln to be revealed soon: Sona Sarmadi (Oct 15)
- Re: Truly scary SSL 3.0 vuln to be revealed soon: Pierre Schweitzer (Oct 14)