25 votes

CVE-2020-19909 is everything that is wrong with CVEs (false bug report for curl)

Tags: security, nvd, bugs, cve

1 comment

  1. tauon
    (edited )
    Link
    Something I found pretty interesting and wanted to already share here when the update to the initial blog post was originally published in early September, but then of course forgot to do. Some...

    Something I found pretty interesting and wanted to already share here when the update to the initial blog post was originally published in early September, but then of course forgot to do.

    Some highlights:

    On August 25 2023, we got an email to the curl-library mailing list from Samuel Henrique that informed us that “someone” had recently created a CVE, a security vulnerability identification number and report really, for a curl problem.

    We can’t tell who filed it. We just know that it is now there.
    Integer overflow vulnerability in tool_operate.c in curl 7.65.2 via crafted value as the retry delay.

    And then the craziest statement of the year. They grade it a 9.8 CRITICAL issue. With 10 as a maximum, this is close to the worst case possible, right?

    This means that on a 64 bit machine, if you write

    curl --retry-delay 18446744073709552 ...

    The number will overflow the math and instead of waiting until the end of the universe, it might retry again within the next few seconds. The above example apparently made it 384 seconds instead. On Windows, which uses 32 bit longs, you can get the problem already by asking for more than two million seconds (roughly 25 days).

    A bug, sure. Security problem? No. I told Jason that in 2019 and then we closed the security report. I then filed a pull-request and fixed the bug. Credits to Jason for the report. We moved on. The fix was shipped in curl 7.66.0, released in September 2019.

    The issue listed by NVD even links to my pull request I mention above. There is no doubt that it is the exact same bug they refer to.

    Spreading like a virus

    NVD hosts a CVE database and there is an entire world and eco system now that pulls the records from them.

    NVD now has this CVE-2020-19909 entry in there, rated 9.8 CRITICAL and now this disinformation spreads across the world. Now when we search for this CVE number we find numerous sites that repeats the same data. “This is a 9.8 CRITICAL problem in curl” – when it is not.

    And then from the update post:

    Rescore

    As a rejection of CVE was denied, the secondary goal would be to lower NVD’s severity score as much as possible.

    Their email highlighted three specific items in the CVSS score and how they could maybe re-evaluate them to a lower setting. How do they base and motivate that? Providing links to specific reddit discussions for details of the CVE-2020-19909 problems. Postings done by the ordinary set of pseudonymous persons. Don’t get me wrong, some of those posts are excellent and clearly written by skilled and knowledgeable persons. It just seems a bit… arbitrary.

    I did not participate in those discussions and neither did any curl core contributor to my knowledge. There are simply no domain experts involved there.

    No reading or pointing to code. No discussions on data input […]. No mention on why no or a short delay would imply DOS.

    Eventually, their proposed updated CVSS ends up with a new score of…

    3.3

    To be honest, I find CVSS calculations exhausting and I did not care to evaluate their proposal very closely. Again, this is not a security problem.

    My take on this: I get that CVEs have good reason to be assigned by independent authorities, as outside of open-source, vendors might tend to, ahem, brush over security issues and bugs. But belittling the lead developer of curl like this multiple times (I left out from my short summary some golden email responses) when the non-issue at hand had been identified and fixed for years already is just… puzzling, at best. I'm sure Daniel Stenberg has got better things to do than dealing with what boils down to fear-mongering database entries.

    Late edit: I also wondered how common of an occurrence this is, is it rather rare or relatively widespread, just seldom ever publicized?

    9 votes