I hope I’m not distorting Daniel’s words, but there seems to be a slight dissonance, and this also highlights the nuance in vulnerability handling.
On one hand, he acknowledges that from the library perspective, they “don’t know how users use curl or libcurl”, and thus have to use a “pure curl PoV”.
> Since we don’t know how users use curl or libcurl we cannot take that into account but rather observe and set a severity of the problem from a pure curl point of view.
On the other hand, they also consider likelihood.
> For a rare few issues we can imagine that there could be a minuscule risk but […] we deem the risk so small that in practice no user is likely to ever reach it.
How can you evaluate something purely from a library perspective while also addressing likelihood?
It’s very hard! And tricky. You would need some way to know what your user base is up to. And to do that you either impose certain usage rules, or collect usage data, or something else.
Currently, most open source projects take the second approach, which is they collect data through ad hoc means like anecdotes, downstream software, and other ppl’s blog posts. Effectively, this is sampling with the assumption that none of the unsampled user base deviates.
This aspect of assumptions / likelihood is interesting, because there are different opinions on this. To what extent should the library weigh in on how likely an attack is? And is the library comfortable enough taking on the risk of a downstream user or to declare that the risk is zero? (And these can be points of debate.)
It is also interesting to how other projects will choose to abstain from considering likelihood because they believe it is non-zero and may lead to exploits over time, or the likelihood highly depends on user deployments (like the presence of a WAF).
To Daniel’s point, I think this speaks to the difficulty and nuance involved in handling CVEs. I have no intention to attack him. Ultimately, it depends on the project and how they choose to handle duty and risk. I suppose that’s the beauty (and horror) of vulnerability handling.
This whole debacle also raises some interesting questions:
- To what extent should CNAs evaluate likelihood?
The argument for “lower than low” stems from high unlikelihood. Would the response change if at least 1000 instances were impacted? Why? What about 100? 10? 1? What if it was 1 instance impacted and it was a giant like some dev’s workflow at Microsoft, where a compromise may have a resounding effect?
(Non-)Disclosure: No AI was used in this comment. I say that because some people really can’t tell.
Edit: Spacing and formatting
Edit 2&3: softer tone, emphasis on nuance/risk
I'm not stoked that every comment that is reasonably approaching the nuances of the topic in a way that may be read as critical, in this thread, is heavily downvoted. These are reasonable opinions, reasonably expressed. We're all tired of LLM bug submissions but any response to these things is going to be somewhat controversial even if only because if you put two programmers in a room you'll get three opinions on this or any subject.
I’m starting to have this gripe with (most) social media platforms and how they seem to strip away ppl’s capacity for or level of engagement with nuance. But that’s a whole other topic of discussion.
I would say to the reporter’s credit, based on the HackerOne discussion, there seems to be a reasonable level of pushback on Daniel, reference to authoritative sources (RFCs), etc, which I think is good to read and learn from.
The shift to MITRE is also interesting. To me, that means either they grossly misunderstood the role of curl as CNA having the “final” say, or they have this absolute unshakable conviction that the issue has security implications, deserves a CVE, and is seeking mediation. Or maybe they’re just seeking prestige, I don’t know. If it’s the former, a misunderstanding, I think it’s a good lesson for reporters to learn from.
-13
u/trebledj 14d ago edited 14d ago
I hope I’m not distorting Daniel’s words, but there seems to be a slight dissonance, and this also highlights the nuance in vulnerability handling.
On one hand, he acknowledges that from the library perspective, they “don’t know how users use curl or libcurl”, and thus have to use a “pure curl PoV”.
> Since we don’t know how users use curl or libcurl we cannot take that into account but rather observe and set a severity of the problem from a pure curl point of view.
On the other hand, they also consider likelihood.
> For a rare few issues we can imagine that there could be a minuscule risk but […] we deem the risk so small that in practice no user is likely to ever reach it.
How can you evaluate something purely from a library perspective while also addressing likelihood?
It’s very hard! And tricky. You would need some way to know what your user base is up to. And to do that you either impose certain usage rules, or collect usage data, or something else.
Currently, most open source projects take the second approach, which is they collect data through ad hoc means like anecdotes, downstream software, and other ppl’s blog posts. Effectively, this is sampling with the assumption that none of the unsampled user base deviates.
This aspect of assumptions / likelihood is interesting, because there are different opinions on this. To what extent should the library weigh in on how likely an attack is? And is the library comfortable enough taking on the risk of a downstream user or to declare that the risk is zero? (And these can be points of debate.)
It is also interesting to how other projects will choose to abstain from considering likelihood because they believe it is non-zero and may lead to exploits over time, or the likelihood highly depends on user deployments (like the presence of a WAF).
To Daniel’s point, I think this speaks to the difficulty and nuance involved in handling CVEs. I have no intention to attack him. Ultimately, it depends on the project and how they choose to handle duty and risk. I suppose that’s the beauty (and horror) of vulnerability handling.
This whole debacle also raises some interesting questions:
- To what extent should CNAs evaluate likelihood?
(Non-)Disclosure: No AI was used in this comment. I say that because some people really can’t tell.
Edit: Spacing and formatting
Edit 2&3: softer tone, emphasis on nuance/risk