3 ms·

Trying to submit a vulnerability they had no intention of actually allowing to ship to the public is not that different from finding serious vulnerabilities wit

by lrvick 6y ago

Trying to submit a vulnerability they had no intention of actually allowing to ship to the public is not that different from finding serious vulnerabilities with no intention of using them. There also might be middle ground where people submit benign code that clearly demonstrates highly risky behavior the reviewer should have noticed. Maybe I introduce code that covertly exfiltrates memory from a non sensitive address, but it is enough to understand I could have chosen a more sensitive one. Or code that simply executes a ping to my server, etc. Anyway, the point is, intent matters.

luckylion 6y ago
> Trying to submit a vulnerability they had no intention of actually allowing to ship to the public is not that different from finding serious vulnerabilities with no intention of using them. It is different in that looking for vulnerabilities in code only costs you time, trying to introduce vulnerabilities costs the other person's time as well, and often producing vulnerabilities scales much better, e.g. you could write some tool that mails them patches, while they'd have to individually judge the merits. > There also might be middle ground where people submit benign code that clearly demonstrates highly risky behavior the reviewer should have noticed. I don't think so. The issue isn't so much with trying to get code reviewed, it's with wasting people's time. That they did so by trying to introduce bugs is just the icing on the cake. If you get consent, you can have all your tests and strengthen the infrastructure, without eventually breaking the system because every other "researcher" submits bogus code every day in hopes to have one slip through and write a paper on how they proved that project x is exploitable. I've noticed the same with general bounties. When you have a security.txt or are on hackerone etc, you'll get lots of useless automated submissions that are wasting your time. Once that happens, you'll either shut down the program, or start rejecting reports automatically which includes the possibility of a false positive.

by lrvick 6y ago

luckylion 6y ago

> Trying to submit a vulnerability they had no intention of actually allowing to ship to the public is not that different from finding serious vulnerabilities with no intention of using them. It is different in that looking for vulnerabilities in code only costs you time, trying to introduce vulnerabilities costs the other person's time as well, and often producing vulnerabilities scales much better, e.g. you could write some tool that mails them patches, while they'd have to individually judge the merits. > There also might be middle ground where people submit benign code that clearly demonstrates highly risky behavior the reviewer should have noticed. I don't think so. The issue isn't so much with trying to get code reviewed, it's with wasting people's time. That they did so by trying to introduce bugs is just the icing on the cake. If you get consent, you can have all your tests and strengthen the infrastructure, without eventually breaking the system because every other "researcher" submits bogus code every day in hopes to have one slip through and write a paper on how they proved that project x is exploitable. I've noticed the same with general bounties. When you have a security.txt or are on hackerone etc, you'll get lots of useless automated submissions that are wasting your time. Once that happens, you'll either shut down the program, or start rejecting reports automatically which includes the possibility of a false positive.