I can kinda understand the motive for carpet bombing an issue tracker with AI slop hoping for a hit, but then to whine about unprofessional responses is really too much. Time to unplug the chatbot.
Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
41–50 of 78 posts
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#42I guess what I'm trying to say is: would it not be safer and more ergonomic to use some struct of pointer+size and pass that around just like higher level languages pass around arrays with a known length? That way the invariant that the size of the allocated memory actually matches the size field can be preserved?
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#43Aaaand he's gone.. https://hackerone.com/napol-webug New angle of DOS attack? Generate bug reports in hundreds, or thousands and practically DOS maintainers of OSS projects.
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#44Apart from the LLM bs, it looks like spammers exploit the fact that they can submit bug reports at no to little cost, while the maintainers have to spend a significant amount to triage the reports. If this spamming goes out of control, then I think it will be inevitable that maintainers will need to charge money to triage bug bounty reports to balance this out somewhat. This would obviously suck for all legitimate pa…
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#45Earlier quoted context omitted.
I formerly worked in triage for a bug bounty program. We paid attention to these kinds of reports because it's often possible to bypass the WAF, or at least repurpose the vulnerability in a way the WAF wasn't designed to defend against.
Absolutely! If you have a known SQL injection behind a WAF, you better go fix it! It seems like these reports come down to the equivalent of “I pasted HTML into a form and you displayed the escaped version back to me, but maybe you forgot some tag.” No, I’m not going to turn off our WAF so you can test that hypothesis.
It would be worth your while to test it. You could run a dev/testing version of your app on a separate domain, without a WAF, and without any sensitive data held on it.
WAFs are a last resort to fix the bugs you didn't know about, and your application should still be safe without a WAF otherwise you're not actually getting the defense-in-depth you wanted. For an attacker that cares enough, WAF bypasses are a near inevitability.
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#46I can kinda understand the motive for carpet bombing an issue tracker with AI slop hoping for a hit, but then to whine about unprofessional responses is really too much. Time to unplug the chatbot.
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#47I got hit with a CVE spammer last year which forced me to re-release a library to fix a fake vulnerability that cannot be disputed in any way -- https://gist.github.com/6en6ar . They do nothing but post exploits where long strings purportedly take a long time to process -- because they are slow to construct! And even more fun, the example exploits often don't even compile. I assumed it was a human, but I'm starting t…
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#48Aaaand he's gone.. https://hackerone.com/napol-webug New angle of DOS attack? Generate bug reports in hundreds, or thousands and practically DOS maintainers of OSS projects.
If I found a really valuable exploit that I wanted to avoid seeing fixed for at least a few months, then why now swamp the project with false positives for a period of time so that my exploit, if it's found, is just one of hundreds being reported and IF it's reported, there is a chance it's being drowned or even accidentally removed.
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#49I can kinda understand the motive for carpet bombing an issue tracker with AI slop hoping for a hit, but then to whine about unprofessional responses is really too much. Time to unplug the chatbot.
I also understand the "motive": money. If you can spam enough maintainers with bullshit vulnerability reports, there's a chance you'll hit something real or trick a maintainer and get a pay-out.
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#50I can kinda understand the motive for carpet bombing an issue tracker with AI slop hoping for a hit, but then to whine about unprofessional responses is really too much. Time to unplug the chatbot.
The complaint sounds AI-generated as well, like the rest of the comments from that user.