daniel:// stenberg://

3 months ago

daniel:// stenberg://
3 months ago

Meanwhile, if you abuse the API and don't comply, asan might complain but that's not a #curl security problem.

curl disclosed on HackerOne: ## Title Heap Use-After-Free...

## Summary A **Use-After-Free (UAF)** vulnerability was discovered in `curl` at **`curl_trc.c:195`**. When processing specially crafted input, the code accesses memory after it has already been...

^HackerOne

#curl

in reply to daniel:// stenberg://

Elias Mårtenson

in reply to daniel:// stenberg:// 3 months ago

Suppose one wanted to honour such reports, what on earth is the curl library supposed to do to prevent this?

I can't even think of a theoretical way to do that, and I don't think the reporter did so either. I suspect they just ran a fuzzer and never even understood what had happened.

in reply to Elias Mårtenson

daniel:// stenberg://

in reply to Elias Mårtenson 3 months ago

@loke right, there's no way we can prevent this from happening. You could *possibly* argue that the API is a little fragile designed here, but that's a decision we took 25 years ago so a little late to change now.

And yeah, I think the reporter here did not actually read the documentation properly or perhaps not not properly understand it.

@Elias Mårtenson

in reply to daniel:// stenberg://

Elias Mårtenson

in reply to daniel:// stenberg:// 3 months ago

I'd go as far as suggesting that security reports that assumes that the product being reported is used wrongly should not be CVE worthy at all.

I could see a case being made for some kind of advisory, similar to CWE's, but relating to specific products: "how to avoid common security issues when using the curl API" or something like that.

But CVE's should always assume that the product is used correctly. I believe that a majority of the noise in the CVE ecosystem comes from reports assuming that the product is used incorrectly.

in reply to Elias Mårtenson

daniel:// stenberg://

in reply to Elias Mårtenson 3 months ago

@loke I completely agree and we clearly state that in our guidelines: if you're not adhering to the API and follow what the documentation states, we can't guarantee anything and they are left on their own - and that's not what CVEs are for.

@Elias Mårtenson

in reply to daniel:// stenberg://

Elias Mårtenson

in reply to daniel:// stenberg:// 3 months ago

Yes, and you can enforce that by being a CVE authority, no?

Sadly, the in general, this is not enforced, and it causes a lot of work for downstream consumers of CVE data. The more I work with CVE data, the more frustrated I get. At least when it's a curl issue, I know I can take it seriously.