Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

hackerone.com

Post reply on HN
Print view View original

21–30 of 78 posts

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#21

Post by mmastrac »

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 to wonder if this was an early CVE-farming AI bot.

The CVE process is very broken and extremely exploitable as a DoS against humans.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#22

Post by resonious »

> 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!!"

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#23

Post by dathery »

jrpelkonen wrote: post #2

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.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#24

Post by kstrauser »

resonious wrote: post #22

> 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

#25

Post by bean-weevil »

kstrauser wrote: post #24
resonious wrote: post #22

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

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.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#26

Post by kstrauser »

bean-weevil wrote: post #25
kstrauser wrote: post #24

Earlier quoted context omitted.

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.

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.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#27

Post by minitech »

mmastrac wrote: post #21

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…

> exploits where long strings purportedly take a long time to process -- because they are slow to construct!

That’s not an accurate characterization of ReDoS. Even if a long string is required to produce the behavior, the vulnerability is that the string takes a disproportionately long time to process even for its length, such that it becomes disproportionately easy to bring down a service. The CVE scoring system gives denial of service way too much weight if you ask me, but it’s not a fake vulnerability.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#28

Post by cozzyd »

I mean, if the reporter actually tried following the PoC they might have realized it's not a valid PoC. (Though to be fair, perror does return a confusing error message in that case).

At first I thought they were trying to make the claim that if you lie about size, you can (duh) get a buffer overflow, but they didn't even successfully manage that.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#29

Post by bawolff »

dathery wrote: post #23
jrpelkonen wrote: post #2

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.

Well i agree, in my experience in the past, lots of reports that looked like junk reports were actually real. I've seen lots of security reports with nonsensical explanations, very broken english to the point you can't follow, and then you run their PoC and it shockingly works.

Triaging security reports is exhausting and very hard.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#30

Post by bawolff »

minitech wrote: post #27
mmastrac wrote: post #21

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…

> exploits where long strings purportedly take a long time to process -- because they are slow to construct! That’s not an accurate characterization of ReDoS. Even if a long string is required to produce the behavior, the vulnerability is that the string takes a disproportionately long time to process even for its length, such that it becomes disproportionately easy to bring down a service. The CVE scoring system giv…

However i think there are people spamming fake redos vulns just to get creds. Things like, yeah, if you passed in 10 mb of input this would be a problem, but also some other layer limits it to 100 bytes.

ReDos is real in certain circumstances, but it is way way overhyped and usually bullshit.

Post reply on HN