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

https://hackerone.com/reports/3302518

@bagder Attached fuzzer not matching with the provided ASAN report is an especially nice touch...

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

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

@buherator Hehe, I didn't even notice that. I just started with reading the attached fuzzer code and found the mistake in there almost instantly

@bagder I started by tracking back line numbers, good for you to have some experience with the curl API :)

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

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

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

@loke absolutely, we never allow crap like that through to become an actual CVE. It's just sloppy reporting that doesn't help anyone.

@loke @bagder As pentesters we regularly argued about whether a behavior can be considered a vulnerability or not. A resolution strategy that almost always worked is to ask ourselves what our recommended fix would be. Maybe including such a question in the report template could help prevent/resolve similar misunderstandings?

@buherator @bagder Probably. I think good pentesters know how to handle this, and will take this into considering when finalising the report with the customer.

The problem is that there are some bad incentives around bounties though. There is a financial interest in the pentester to get the severity as high as possible. And even if they don't get a monetary award, the testers reputation will improve if they can show they've found a lot of severe vulnerabilities.

Good testers working for serious customers don't have this problem, because then the incentive is to provide a useful and actionable report to a customer, and in my experience those reports tend to be useful.

But there is also the problem that the CVSS scoring system doesn't take this into consideration, so when a formal scoring is done, the fact that the there is an assumption that the system is misconfigured isn't reflected in the final score, at least not to the degree it should.

@loke @bagder Bug bounty absolutely has perverse incentives, and even I'm not sure if my previous idea can be realistically implemented in this context. It's just an idea and maybe something to ponder on case anyone is facing a similar dilemma.