Live data from Hacker News

Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

hackerone.com

31–40 of 78 posts

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#31
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.

In the google cache for that you can find a link to https://webug.xyz/, which is... something.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#34

> That being said, in cases where the check may be bypassed or in a different implementation scenario, similar vulnerabilities can still appear. This is so funny. "Oh, I see you have a bounds check that prevents vulnerability. BTW, if you remove that bounds check, your code will be vulnerable!!"

We get bug bounty reports like that sometimes. "I think your site might have an XSS vulnerability but your WAF is stopping it." "What I hear you saying is that we don't have an XSS vulnerability." I mean, it's possible we do have a mistake in code somewhere we haven't found yet, but if the system effectively protects it, that's not a vulnerability.

This WAF scenario is different, it's a porous unreliable last line defense, like anti-virus. Having a mitigation stop something != not having the vulnerability in the first place.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#35
post #31
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.

In the google cache for that you can find a link to https://webug.xyz/ , which is... something.

How do you access google cache?

    cache:https://hackerone.com/napol-webug 
Does not work for me. Is there a still working method?

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#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 parties involved.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#37
post #35
post #31

Earlier quoted context omitted.

In the google cache for that you can find a link to https://webug.xyz/ , which is... something.

How do you access google cache? cache:https://hackerone.com/napol-webug Does not work for me. Is there a still working method?

the website link appeared in the quoted results when googling napol-webug, at least for me.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#38
There’s absolutely no excuse for filing utter shit like this. The POC is two lines of Bash, and the author couldn’t be bothered to even run that.

https://github.com/webug-lab is presumably the author.

People who file reports like this should be permanently banned from HackerOne and excised from the security community. They are parasites, leeching off of the time of open-source maintainers.

I can’t believe how nice badger is on the thread, frankly. He is well within his rights to be much harsher.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#39
post #23

I feel sorry for the maintainers having to spend their energy disproving the validity of these AI generated reports. Daniel Stenberg blogged about this issue earlier: https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f... Open source burnout is already real, I hope the volume of the AI slop security reports stays manageable.

I really like his quote: "a well-formed crap report is harder and takes longer to discard". I think that cuts to the core of why people feel betrayed when they suspect they're being fed unlabeled AI content. You see the well-formatted paragraphs, the precise explanations, and you naturally extend a bit more effort in reciprocation. There have always been junk bug reports, but they used to look like what they were.

IOW, older heuristics (meant to screen out below par human work) no longer function. Newer AI-specific heuristics are needed. Which is precisely what we're all developing, often without realizing.

Unfortunately there's a bit of a perverse feedback loop in that Pinocchio wants to be a real kid.

Post reply on HN