[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] The Internet Bug Bounty: Data Processing (hackerone.com)
From:       Kurt Seifried <kseifried () redhat ! com>
Date:       2017-09-29 14:42:08
Message-ID: CANO=Ty1WTxQjjqZt6KALD2hrfubJYG2gbZKaLVewG1o9KMA2XA () mail ! gmail ! com
[Download RAW message or body]


On Thu, Sep 28, 2017 at 5:03 PM, Guido Vranken <guidovranken@gmail.com>
wrote:

> I found a buffer overflow in one of the projects within 30 minutes,
> and there are probably many more issues to be found (as in virtually
> any large, unaudited project). What makes this project special
> compared to other bug bounties for C libraries (such as the regular
> Internet Big Bounty programs) is that they require a full, reliable
> exploit.
>
> If they would be willing to be lenient in their qualification of what
> constitutes a working exploit, such as exploitation of a binary
> without advanced anti-exploit protections such ASLR, I might bother,
> otherwise I won't. Enhancing open source projects is a honourable
>

The simple reason being is it gets rid of all the chaff and time wasters.
Anyone can run a fuzzer and find a crash case. That's not what we need, we
need a root cause analysis that identifies where in the code it failed, or
a reliable exploit that causes code exec so we can do the research and
actually figure out if this is exploitable or not. Their money, their rules.



>
> All in all I think they should reconsider their current program
> stipulations, if only to increase their own return-on-investment
> (making the internet safer with a limited funding).
>
> Guido
>

I think you're forgetting about the cost of analyzing a lot of false
positives. This is why I push back and ask for more information on a lot of
CVE requests now.


-- 

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com


[prev in list] [next in list] [prev in thread] [next in thread]