The CVE system is broken. How can we fix it?

As Daniel Stenberg told us, the recent CVE filed against curl is bogus, and the system to fix it is even more bogus. See his article about his efforts to get the CVE revoked, or at least re-evaluated on daniel.haxx.se.

To summarize the reason for the CVE, a little over four years ago somebody filed a CVE against curl because it didn’t check a command line argument before multiplying the value with 1000 and use it as a timer before retrying a failing request. This was, however, not a security problem, because the worst thing that could happen was that curl retried after a few seconds when you give it a ridiculous amount for that timeout (25 days on Windows which is still stuck in 32bit, “the end of the universe” - as Daniel put it - on a 64bit machine).

However, the same could be achieved by setting that timeout to 1 second in the first place, which somehow makes this only a more complicated way to do something potentially stupid (or a denial-of-service, as NVD calls it).

Mitre and NVD play dumb

Mitre denied the request to reject the - clearly bogus - CVE because it could lead to a denial of service (what, of retrying after seconds instead of the 584 million years that were requested?). Which basically means retrying any failing network requests is basically a denial of service. Seriously.

The NVD however proves it is only a bureaucratic government entity and certainly does not consist of any technical people at all, because they for starters reject removing it, but they also want to keep the original (bogus) score of 9.8, because apparently multiplying two integers can lead to undefined behaviour. Actually, it is very much defined, either it is clipped and the resulting number of seconds (which, I repeat, could be a perfectly normal value of 0 or 1) or the program aborts with an error message about an integer overflow if the runtime library or the compiler provide that sort of extra testing.

Do your own research

To test this, I wrote a small program to show exactly this behaviour and compiled it with two different C compilers, gcc and clang (I just used the number Daniel used in his article):

#include <stdio.h>

int main(void) {
    long int n1 = 18446744073709552;
    long int n2 = 1000;

    printf("%ld\n", n1 * n2);
    return 0;
}

As can be proven by experimentation, absolutely nothing can change this program to output anything else but 384. Exactly what Daniel wrote in his article. How this is supposed to be “undefined” boggles the mind.

Ah, but what happens with some future compiler, on a future OS? Well, either it redefines multiplication (not likely) or it returns one of two values: 384, or 18446744073709552000. In the latter case you really have to wait until the end of the universe. So, is that a security vulnerability? No. A change in behaviour in case somebody redefines long integers to be 128 bits long, but still not undefined behaviour.

And still just a bug.

Which btw. was fixed four years ago, in september 2019, for curl 7.66.0 (and I’m running curl 8.2.1 right now).

The problem with RedHat

But that brings me to another problem, RedHat. The main product of RedHat is RedHat Enterprise Linux, or RHEL for short. Right now there are three versions still in active production (meaning they get updates, for security and otherwise). So that means RHEL8 is mainstream right now, RHEL7 is nearing EOL in june 2024 (still nearly a year away), and RHEL9 is still quite new.

In RHEL7 the current version of curl is 7.29.0. Long before 7.66.0. Even the “mainstream” version RHEL8 only has 7.61.1. Does it have the fix from 2019? There may be some way to see if the fix has been backported - as they do in RHEL - or not. However, do you, as a corporate sysadmin, really want to have to check each and every source package for fixes that are in later versions? How about backwards compatibility as in the case of man gimme, where a fix was applied, but someone, somewhere, relied on the bogus behaviour and wants the bug back?

But that’s the trouble with doing Linux “professionally”, corporations want to buy stuff, they want to have a support contract and a telephone number on which they can call somebody and yell at them. Never mind the real consequences.

But ok, rant over, this should maybe be its own article.

Conclusion

Don’t blindly trust CVEs, do your own research. Do check Ubuntu’s security notices, since they are usually much better than anything RedHat can provide, even if you are running RedHat and the notices mention Ubuntu versions.

Do your own research.

Learn C and try stuff. No, really. Don’t be like NVD and rather be ignorant.