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.
Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
31–40 of 78 posts
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#32I 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
#33Re: 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.
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#35Aaaand 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.
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
#36If 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
#37Earlier 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?
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#38https://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
#39I 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.
Unfortunately there's a bit of a perverse feedback loop in that Pinocchio wants to be a real kid.