Re: The Internet Bug Bounty: Data Processing (hackerone.com)

[Reed Loden <reed () reedloden com>]

(Wearing my IBB hat)

I just replied to Guido privately, but wanted to follow-up here stating
that we (the IBB) are open to paying for issues in a non-ASLR configuration.

The main reason we have extra stipulations on this particular program is
that some of the projects that have signed up were worried about being
inundated with low-severity issues that didn't actually do much to improve
security. So, we started with a fairly high bar to emphasize the main goal
of looking for critical vulnerabilities (i.e., RCE). However, ASLR is not
full-proof and only delays the inevitable, so I agree that vulnerabilities
that are solely mitigated by ASLR should still be in-scope for a bounty.

Separately, we're happy to announce that libav (
https://git.libav.org/?p=libav.git;a=summary) was added to the scope
earlier today.

If other well-known projects fit into the category of "data processing" and
wish to participate, please reach out to panel [@] internetbugbounty.org,
and we'd be happy to add you.

Happy hacking,
~reed
(for the Internet Bug Bounty)

On Thu, Sep 28, 2017 at 4: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
> pursuit indeed and I've done it many times for free, but if I'm going
> to hack for money I might as well choose something that is easier or
> more profitable or both at the same time. You can fetch $500 for any
> old XSS on a web page or a buffer overflow in the clusterfucks that
> are the PHP and Python code
> (https://hackerone.com/directory?query=ibb%3Ayes&sort=published_at%
> 3Adescending&page=1
> -- see the sheer number of submissions to both those programs).
>
> Right after the program was announced, I sent an email to the IBB
> asking if exploitation of a non-ASLR configuration of the binary at
> hand would be sufficient. Unfortunately, I have not yet received a
> reply. The reason they want full exploits is, I think, to cut the
> chaff from the grain and solicit bugs that at least have real
> potential. A nice middle ground would be paying a percentage (25%?) of
> their current bounty offering for raw submissions of bugs that are
> generally assumed to constitute a security risk. It will attract a
> larger body of researchers for sure, and in the end this will be more
> beneficial to the overall security of the internet than under their
> current approach.
>
> A Heartbleed-like vulnerability in an image parsing or conversion
> library, where an attacker can send a crafted image file resulting in
> exposure of unrelated memory, would not be eligible under this
> program. Case in point: see Chris Evans' Yahoobleed:
> https://scarybeastsecurity.blogspot.nl/2017/05/bleed-
> more-powerful-dumping-yahoo.html
>
> 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