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

51–60 of 78 posts

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#51

Post by bluGill »

alkonaut wrote: post #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…

It is too late to do that. C was built in the 1970's when buffer overflows where only exploited by friends to get a laugh and so they were not security issuses.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#52

Post by Karellen »

DanielVZ wrote: post #17

Having contributed my small grain of sand to the curl project in the past, I can only say I have huge respect for badger. All the issues I worked on he was impressively active on and even though I was a newbie and his language came across a bit terse when making comments, he was never wrong or disrespectful. I can’t imagine how much strain is AI slop putting on curl maintainers so I hope there’s a solution to that in…

* bagder

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#53

Post by secondcoming »

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…

Bad regex took down cloudflare due to backtracking.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#54

Post by sourcepluck »

@dang, or whoever has the power to do so:

Can the title be changed? It is the exact title of the "report", but it's not a real report, and that's the story here. Keeping the real title of the fake AI-slop-report only adds to the confusion.

It's hard to do a neutral, descriptive, non-editorialising, non-clickbait title, but perhaps along the lines of:

> Curl maintainers lose time dealing with AI-generated fake security report

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#55

Post by magicalhippo »

alkonaut wrote: post #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…

The problem with C isn't that we can't add things to make it safer. It's that we can't remove things to make it safer.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#57

Post by jerf »

Retr0id wrote: post #45
kstrauser wrote: post #26

Earlier quoted context omitted.

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

It may be worthwhile to test, but the strength of "I see this field is correctly encoded but maybe hypothetically it could be your WAF protecting a vulnerable application. My sole supporting reason for this hypothesis is that if it is true, your bug bounty program will pay out for me" is, as vulnerability signals go, too uselessly weak to act on.

Bug bounty programs are nifty in that they give real researchers an effective outlet for the things they were quite possibly going to discover anyhow, but part of the price of that is you get a lot of submissions from people basically treating it as a system for spraying bug bounty programs with lottery tickets with low effort.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#58

Post by razze »

We're also seeing symptoms of this in software support. Specifically with flatpak for example, as people start to recommend or wonder about flags (that have never existed) not working.

Some even end up writing (abusive) issues about that https://github.com/flatpak/flatpak/issues/6006

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#59

Post by negatendo »

cozzyd wrote: post #31
Fokamul wrote: 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.

dude is creating capital and asset funds for a business that doesn't yet exist. i'm afraid we've got a clinical case of the silicon valley brain worms here folks.

Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4

#60

Post by kstrauser »

Retr0id wrote: post #45
kstrauser wrote: post #26

Earlier quoted context omitted.

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

Please give me the benefit of the doubt and assume that we actually do test things. As I assume you’re good at what you do, so am I. The WAF thing was an example of the sort of report we commonly get: “if you turn off all the mitigations, it may be possible to attack you!” Yes, but we use defense in depth so that the mitigations help cover any gaps we might’ve missed, and if the end result isn’t exploitable, it isn’t exploitable.

Just like in the original report here: “if you turn off those checks, it could be vulnerable!” “Yes, but we’re not about to do that because we’re not insane.”

Post reply on HN