C says if we do signed arithmetic and there's an overflow, that's Undefined Behaviour. The compiler can transform the program in any way it sees fit so long as it preserves observable behaviour - all transforms of UB are valid, so the behaviour of the software in this case is in reality completely arbitrary. This "not a vulnerability" could cause absolutely anything to happen.

I have absolutely no doubt that this "not a vulnerability" distinction is not useful, and I suspect it's actively harmful. If your program has documented behaviour but it doesn't actually do what was documented it's not useful to pretend to know whether this deviation is or is not a "vulnerability". My guess is that in insisting that some cases are and some are not, you help bad guys circle the pieces of your system you're not actually defending...

I understand Daniel's instinct. But it's misdirected here. If the worst bug you had in 2020 was an integer overflow in command line parsing code that's not a bad year, take the win. Unfortunately it wasn't the worst Curl bug in 2020.

For whatever it's worth, this variable should have a Duration type but neither C nor its standard library provide one. And so everything flows from there. Why are we multiplying it by 1000? Because we have a retry wait in seconds but we want to calculate milliseconds. In C instead it's a signed "long" integer and of course those have Undefined Behaviour on overflow.

In the more recent CVE that Daniel mentions it's a different cause of Undefined Behaviour. In this case a classic one-past-the-end pointer dereference. But again, Daniel characterises it as fine, because in his mind the worst case is a crash, even though "Undefined Behaviour" is not in fact specified as "Don't worry, it's fine, worst case it will crash"...

Mostly the (presumably unintended) effect of this article was to make me think Curl is worse software and the people maintaining it have prioritised their personal feeling of self-worth and aren't too bothered whether the software is good.

Posted Feb 23, 2024 16:58 UTC (Fri) by JoeBuck (subscriber, #2330) [Link]

Undefined Behaviour as usual

Posted Feb 23, 2024 17:02 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

Undefined Behaviour as usual

Posted Feb 23, 2024 17:34 UTC (Fri) by flussence (subscriber, #85566) [Link]

Undefined Behaviour as usual

Undefined Behaviour as usual

WCHAR prefix[3] = {0};
if (something) {
    DEBUGASSERT(prefix[3] == L'\0');
    more stuff;
}

#ifdef LINUX
#define NUMBER_OF_THINGS 10
#else
#define NUMBER_OF_THINGS 5
#endif

thing_t things[NUMBER_OF_THINGS] = {0};
if (some_function_in_another_file_that_only_succeeds_on_linux()) {
    thing[7] = something;
    more stuff;
}

Posted Feb 23, 2024 17:37 UTC (Fri) by mgb (guest, #3226) [Link]

Undefined Behaviour as usual

Posted Feb 23, 2024 18:36 UTC (Fri) by geofft (subscriber, #59789) [Link]

A vulnerability is a misbehavior in a program that compromises its security in response to crafted input / malicious actions from an attacker. This requires a few things to exist. "Misbehavior" requires a coherent concept of intended behavior. "Attacker" and "crafted input" require a system that interacts with untrusted parties in some way. "Security" requires things that you're trying to keep secure (maintain confidentiality, integrity, and/or availability) from the attacker.

As an obvious example, the fact that bash executes arbitrary code is not an arbitrary code execution vulnerability. It's what bash is supposed to do. The thing that supplies input to bash is expected to be the legitimate user of bash, not an attacker. bash is supposed to be able to run any command, and so it doesn't have a distinction between behavior and misbehavior. If you can get arbitrary code execution in rbash, for instance, then yes, that's a vulnerability, because rbash is designed to take untrusted input and maintain security of the system it runs against that input. If you can run arbitrary commands by setting environment variables even if you can't control input, then there's probably a vulnerability (as Shellshock was). But for regular bash, if you are setting up a system where you're piping untrusted input into bash, that's a vulnerability in your system, not in bash.

The only way to distinguish that is to know at a human level what bash is supposed to do and where it's supposed to take inputs from. There is no automated technical distinction to be made between bash and rbash. There is no automated technical distinction to determine that commands like bash and python are only intended to be run with trusted input, but commands like grep and sort are supposed to be able to handle untrusted input. You can call this a "gut feeling" if you like, but it's inherent to how we use computers. We never run a program for the sake of running a program; we run a program in order to accomplish some task of human interest, and the parameters of that task, not the program, determine what counts as misbehavior and insecurity.

There is a simple argument that CVE-2020-19909 (note there is a typo in today's article, it's 19909, not 1909) is not a vulnerability. It is not that the undefined behavior doesn't exist, or that the risk of a compiler doing something arbitrarily weird and unwanted is low. It is entirely compatible with a compiler generating code to do system("rm -rf /") in the case of signed integer overflow. The argument is that attackers do not have access to set an arbitrary retry delay value, and any real-world system that uses curl where attackers do have this access has a more fundamental vulnerability - e.g., they can provide arbitrary arguments to the curl command line, or they already have code execution in an address space in which libcurl is linked. Even in the most limited case where the attacker can only specify this one value and nothing other than curl is imposing limits on the value they'd still be able to effectively request that curl should hang for 24 days on a 32-bit system or until well past the heat death of the universe on a 64-bit system, which is already a denial of service vulnerability, and fixing that would avoid hitting the integer overflow in curl. And if you, yourself, as the legitimate user of curl or libcurl provide a ludicrous value for the timeout, it cannot be said to be a vulnerability, because you are not an attacker of your own system.

How do we know if this claim is correct? You're right in a technical sense that you can't really know - it's always theoretically possible that someone wrote a web form that takes input from untrusted users and one of the fields is the retry vulnerability value But it's also equally theoretically possible that someone wrote a web form that takes input from untrusted users and splices it into a bash command line without escaping. And, in fact, it's not just theoretically possible, it's quite common. But nobody would say this means there's a vulnerability in bash, would they?

The process of determining what is or isn't a vulnerability has to come down to human judgment. You could plausibly argue, for instance, that Shellshock wasn't a vulnerability because attackers shouldn't be able to pass arbitrary environment variables into bash. But the real-world deployment of CGI meant that there was a large installed base of users where attackers were in fact able to set environment variables to arbitrary values. Moreover, it meant that humanity believed that it was a reasonable design to do that, and the flaw was not with CGI for setting those variables.

And it's not sufficient to just lean on documented behavior. First, would you consider it an adequate fix for the vulnerability if curl made no code changes but just changed the documentation to say that the input to the timeout value must be small enough to avoid integer overflow? But also there have actually been real-world vulnerabilities, that are unquestionably vulnerabilities in human judgment, that were documented. Log4shell comes to mind: the behavior of loading JNDI plugins in log statements was absolutely intentional, and the support in JNDI for loading plugins from arbitrary servers was also absolutely intentional. But the resulting behavior was so unreasonable that the Log4j authors did not argue "there is no deviation from the documented behavior" - which they could have argued with much more certainty than a gut feeling. Or consider the KASLR bypass from the other day: it isn't material whether the kernel developers intended to publish a world-readable file with post-ASLR addresses or not, it is still a security bug either way.

There is, simply, no way to determine what is or isn't a vulnerability without the involvement of human judgment. You can make a reasonable argument that the maintainers of the software are poorly incentivized to make accurate judgments, yes. But someone has to make the judgment.

(Also - I actually fully agree with you about CVE-2023-52071. The argument that it only applies in debug builds and not release builds is reasonable as far as it goes, but in my human judgment, it is totally reasonable to run debug builds in production while debugging things, and you're right that Daniel's claim that it can only possibly cause a crash is incorrect. Because the bad code deterministically does an out-of-bounds access, it's totally reasonable for the compiler to treat the code as unreachable and thus conclude the rest of the block is also unreachable, which can change the actual output of the curl command in a security-sensitive way. The compiler can tear out the whole if statement via dead-code elimination, or it can lay out something that isn't actually valid code in the true case, since it's allowed to assume the true case never gets hit. He's quite possibly right that no compiler actually does that today; he's wrong that it's reasonable to rely on this.)

Undefined Behaviour as usual

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-5...
https://nvd.nist.gov/vuln/detail/CVE-2023-52071

show “REJECTED” status for me now (and minimal details on what the original claimed vulnerability was in the change history). It seems to have changed earlier today.

So it seems curl becoming a CNA did give them some additional leverage to reject “CVE” reports they thought were bogus.

But the curl project and others are right that the CVE system is pretty broken. And basically designed for the opposite of today’s situation, ie designed to track good faith reports against vendors unwilling to fix real problems. Sadly there’s a lot of momentum behind the CVE system now, so I don’t see it being fixed any time soon. And all vendors just being able to arbitrarily reject any report without documentation is itself vulnerable to abuse too.

Posted Feb 23, 2024 21:34 UTC (Fri) by bagder (guest, #38414) [Link]