Live data from Hacker News

Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

hackerone.com

41–50 of 78 posts

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#41

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.

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

#42
The maintainer vs. AI issue aside: in C when you write a method with a dst pointer and a size_t size argument, is it enough to check the size argument to be sure that the dst pointer will fit the data? It doesn't seem like that would protect against mistakes, for example if I allocate 100 bytes and call the method with 200 for the size_t, then it will pass the check but potentially write out of bounds anyway?

I 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

#43
post #19

Aaaand 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

#44
post #36

Apart 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…

Actually this could be an attack in itself. Say you find a significant 0-day in some popular library. And start exploit it, but you at same time bury the reporting system in generated false leads and reports of non-existing issues. Thus taking time away from actual issue while you actively exploit it...

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#45

Earlier 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.

> 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

#46

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.

Scammers rarely "come clean", even when it's clear both parties know what's up - they don't want to get banned from the host platform.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#47

I 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…

Could we introduce a real monetary cost to posting a bug? That'd disincentivize making massive amounts of noise, but allows people to compete for rewards with worthwhile answers.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#48
post #19

Aaaand 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.

Perhaps I'm too optimistic, but the legit exploit will have a very different style. Perhaps broken English and a 50% code and 50% text instead of 10% code and 90% text. I guess that a fast triage to detect non-cookie-cutter reports would be enough (but anoying anyway).

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#49
post #41

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.

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.

Or you can use your track-record of discovering CVEs as a stepping stone to a cushy infosec job

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#50

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.

The complaint sounds AI-generated as well, like the rest of the comments from that user.

It sounds like a non native English speaker to me. I've worked with many non natives and some speak like that. Of course they also have enough self awareness to know they don't speak good English - some of them with much effort gotten good in a few years.
Post reply on HN