Would be nice if any of future "C is the root of all evil" articles would refer to this ticket as an example.
Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
61–70 of 78 posts
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#62Earlier quoted context omitted.
> 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 eff…
Nailed it. “Rationale: please pay me” is all too common.
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#63Earlier quoted context omitted.
> 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…
I disagree that the WAF situation is comparable.
The curl report (incorrectly) describes missing bounds checks leading to buffer overflows.
If the curl project said "buffer overflows are ok because our code gets compiled with ASLR and NX", then that would be comparable to saying SQLi and XSS are non-issues due to a WAF. Fortunately, that's not what they said.
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#64Earlier quoted context omitted.
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…
I disagree that the WAF situation is comparable. The curl report (incorrectly) describes missing bounds checks leading to buffer overflows. If the curl project said "buffer overflows are ok because our code gets compiled with ASLR and NX", then that would be comparable to saying SQLi and XSS are non-issues due to a WAF. Fortunately, that's not what they said.
It was an example, an analogy, an illustration. We’re not dependent on our WAF any more than curl is dependent on ASLR and NX. We (and curl) use those things in addition to good coding practices so they all work together to create as secure of a product as our respective teams can manage.
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#65This type of thing is my biggest AI fear. It’s just too easy to produce bug reports, twitter posts, academic papers, entire books and audiobooks, using AI. While the results are almost entirely trash, we can’t force humans to take the time to categorize and reject them, as there isn’t enough time. The only fix I can think of is going to be to introduce trust models, where you can vouch for people and their outputs, a…
There should be consumer protection laws in place that require AI companies to record every result their tools produce. Then when some trash human submits the AI output to a bug tracker, forum, etc. with a negative impact on the victim website, they can submit a claim to the AI company for a $100 million payment due to the inability to prevent the tool from being used improperly.
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#66I 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…
You missed the point.
The code purported to be vulnerable is not slow because of the length of the string. The "example exploit" is slow because the reports use slow methods to construct the string under test. When timing the affected methods, they are _not_ slow.
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#67Earlier quoted context omitted.
I would assume that this is evidence that the reporting account has been disabled.
Yes, you can still click through if you don't hover, and the account is gone. Presumably, the code that shows the preview just doesn't handle deleted accounts gracefully.
Unfortunate that they deleted it and didn't / couldn't lock the account and flag all its submissions as suspect while leaving them in place for review.
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#68I 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…
Can you explain how a CVE "awaiting analysis" forced you to "resolve" it? Just wondering how this works.
I looked at the first one (https://nvd.nist.gov/vuln/detail/CVE-2024-25355) and obviously they time way too much of the "vulnerability", attributing their own test setup to your library (as you mentioned).
So- someone reports a CVE (can just anyone do that?), and without any validation, some other services dings your library and now random users ask you "can you please fix your library"?
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#69I 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.
I would rather some sort of authenticated peer-rating system. If someone has a history of making good, useful bug reports- then convey that in some way to project maintainers reading bug reports.
GitHub is in a good position to do this at scale.
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#70I 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…
Can you explain how a CVE "awaiting analysis" forced you to "resolve" it? Just wondering how this works. I looked at the first one ( https://nvd.nist.gov/vuln/detail/CVE-2024-25355 ) and obviously they time way too much of the "vulnerability", attributing their own test setup to your library (as you mentioned). So- someone reports a CVE (can just anyone do that?), and without any validation, some other services dings…
That wasn't the library I had an issue with but the general problem is this:
Downstream consumers of a library that have integrated Dependabot get alerts for CVEs filed against a library, even if the are "awaiting analysis". Those consumers send messages asking for a resolution, and there's no trivial way to push back that an advisory is false.
For example, here's the one I'm griping about. This is marked as _Github reviewed_:
https://github.com/advisories/GHSA-fqhp-rhm6-8rrj
I used the reporter's reproduction and could not reproduce the slowdown at all. It turns out that the testcase was slow only because they were printing the URL under test.
https://github.com/progscrape/urlnorm/issues/1
As a maintainer, I have a choice: either I need to go and clean up all of the automated tools that respond to CVE spam, OR I just release a new version of a library, fuck it all and move on with my life after blocking the reporter.
For what it's worth, Github did not respond to reports about this user, so I got to the point where I think everything is broken and I no longer care about anything other than clearing those alerts out.