1. 119
  1.  

    1. 30

      NVD used this CVSS string to calculate that score of 9.8 Critical: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

      Expanded out, that’s:

      • Attack Vector: Network
      • Attack Complexity: Low
      • Privileges Required: None
      • User Interaction: None
      • Scope: Unchanged
      • [Impact on] Confidentiality: High
      • [Impact on] Integrity: High
      • [Impact on] Availability: High

      …what? This is, at best, a DoS if you somehow gain limited control over curl’s command-line parameters. I have no idea how anybody who’s done, like, 5 minutes of research on this issue can arrive at the values NVD did.

      (I don’t love CVSS anyway - IMO, it deals really poorly with issues that may not be directly exploitable, but might fit into a larger exploit chain - but this is just blatantly wrong.)

      1. 15

        Wait – how does this have any impact at all on confidentiality or integrity?

        1. 8

          No one knows. Maybe NVD knows.

          But probably not. 🤦

      2. 9

        Yes, that 9.8 rating is completely nonsensical in this case, never mind that the underlying integer overflow was fixed years ago.

        If the attacker is at the point where they have some control over the curl command line… they can just change the URL you are trying to download to a malware site. That’s not a curl problem, that’s a problem for whatever was calling curl.

        1. 8

          I guess if something lets the user configure retry-delay, and validates that it’s a number higher than a given threshold, this bug would let an attacker ignore that check? But that’s incredibly niche.

        2. 1

          It’s strange that it’s kept up after the fix was delivered. Say that it was all true and it was a serious bug; it would be wrong to say curl still had the bug if the patch has been merged already.

          1. 10

            Well, that’s the thing. The fix was delivered in 2019. curl had the bug, and it was an ordinary bug, not a CVE. Did the curl maintainers put up a fuss and say it wasn’t a bug? No, they just fixed it and thanked the reporter… four years ago. What rationale did NVD have for bringing this up now and also claiming it was a CVE?

            My take is that NVD was lazy, and hasn’t yet retracted this because they don’t want to admit their mistake.

            1. 1

              Unfortunately NVD is nothing more than essentially twitter for hundreds* of organizations that are supposed to “validate” and “manage” the CVEs. Some of these organizations do outstanding due diligence, some just republish whatever you send them, others try to make everything seem more severe than it is (Best I can tell there is some shady reputation/extortion games going on). I’m not sure what the requirements are to be one of these organizations but its definitely not enough.

              1. 2

                I believe NVD also invented the CVSS score themselves? They say:

                Note: NVD Analysts have published a CVSS score for this CVE based on publicly available information at the time of analysis. The CNA has not provided a score within the CVE List.

    2. 15

      The only purpose of CVEs these days is to function as a public scoreboard for people who find useless vulnerabilities. If the vulnerability is any good, you get a bug bounty or sell it via Zerodium. CVEs are the infosec version of LinkedIn quizzes.

      1. 3

        naa CVE’s get sucked into “security” scanning software that just vaguely fingerprints the version of whatever you are running and spits out a scary report.

        then developer gets to argue with “security” team that this is just some bullshit, wasting countless hours of every ones time :+1:

        the best bit is scanners not accounting for linux distros back porting patches, so “security” person blindly reports to your manager that you are running bazillion year old apache with a million CVE’s… thanks champ!

        1. 3

          Literally have this problem exactly. I brought up that it does not make sense to scan and flag machines used for ML training/inference that are for research only, never serving customers.

          “Defense in depth” I was told, and that “attacks have pivoted from compromising one VM to larger attacks across the network”.

          Which I refrained from pointing out, was a much larger and more pressing security issue if the isolation of VMs was not good enough to protect the rest of the infrastructure. What if someone intentionally compromises a VM? ….

      2. 2

        Since the future is already here today, just not evenly distributed, CVEs also work as sources for n-day inspiration – very much a thing in a world where the basic infotainment whatever runs a half-decade old Android.

        In a similar vein, if you want to stir up some dust when cleaning up, or disseminate honeypot findings, invent a budding researcher to publish through either directly or by farming ‘street cred’ on some hacker forum/discord and let the system do its thing, it’ll eventually CVE itself.

    3. 11

      I think the author of this post makes very good points, but I would like to challenge one of them.

      In C, just because you’re vulnerable to an integer overflow, it doesn’t mean that the only effect of the integer overflow is that the value wraps around, which the author seems to imply would be the worst possible outcome.

      That would be more likely to be true if the overflow was in an unsigned variable [1] or if curl was compiled with -fwrapv (maybe it happens to be?), but the latter is almost always not the case in most programs, which means that a signed integer overflow almost always leads to undefined behavior which can trigger all sorts of other security vulnerabilities, including quite unexpected/unintuitive ones (e.g. safety checks being eliminated, “time traveling” behavior, etc).

      And even with -fwrapv or with unsigned integer overflows, while they don’t trigger undefined behavior directly, they can still trigger undefined behavior indirectly when the wrapped-around values are used elsewhere.

      I’m not saying that this is the case here or that if such other consequences would be found that they wouldn’t be reflected in curl’s assessment of the problem. I’m just saying that I was surprised that the author dismissed an integer overflow as simply being an issue of a value being wrapped around and did not explicitly acknowledge the other potential risks. So I’m hoping the people who read the post don’t get the wrong idea.

      [1] Looking at the post, the author seems to imply that the variable was unsigned, but looking at the fix [2] I only see signed variables, which seems to reinforce my point.

      [2] https://github.com/curl/curl/pull/4166/files

      1. 10

        Daniel’s point in the post still stands - a CVE was created in 2023 with a 2020 year designation, referencing a version of curl with a bug that has since been fixed.

        No-one is disputing that the bug existed. What might have been under discussion is whether it was a bug or a vulnerability, and it’s possible that if a CVE had been created before the bug was fixed, it could be argued that as the behavior is UB it’s ipso facto a vulnerability.

        But that’s not what happened. If you run a current version of curl, this issue is no longer present.

        I think what’s happening is that curl is a very popular product that takes security seriously, and having a CVE filed against it is a merit in the security world. This outfit is trying to take a shortcut to that merit.

        1. 8

          Daniel’s point in the post still stands

          If you reread my comment, you’ll notice I didn’t dispute almost any of Daniel’s points. I only disputed one of them. That’s the only point I wanted to make. As for the other ones, I agree with Daniel.

          I also agree with everything you said.

          And I also think my point still stands: in my view, Daniel’s explanation of the possible security implications of that bug is overly simplistic. It is very likely to lead anyone who is not an expert C programmer to believe that an integer overflow like that one, in C, is just that, and that it cannot lead to a security vulnerability. This is better exemplified in this quote:

          A bug, sure. Security problem? No.

          I mean… Really? No?

          Why not?

          It’s definitely not because of the preceding explanation of what the bug is, I can tell you that much. Since this seems to be causing actual UB, to make the claim that this is not a security problem, you’d really have to dig a lot more deeply into it, including actually looking at how the code is compiled in all the different platforms, with all the different compilers and compiler versions. There’s really no way around that, that I know of.

          And I think any expert C programmer can agree with me, that in that blog post, he has definitely not provided a sufficient argument as to why it’s not a security problem.

          But notice how he didn’t even mention that the bug was causing UB. He didn’t mention or linked to what UB can lead to, especially all the unintuitive consequences.

          So perhaps he simply meant to say that it’s unlikely to be a security problem (based on his previous experience of similar issues). In which case, it would have been better to have worded it like that. Otherwise, in my view it’s just reinforcing the misconceptions that programmers have about integer overflows and undefined behavior in C (which I’ve linked to in another comment in this thread).

          Now to be clear: I haven’t actually looked deeply at the code, but at a first approximation, I agree that it’s unlikely to be a security problem. And this does not affect all the remaining points in his post. I was simply challenging this one claim, which again, I consider important to correct due to the misconceptions that it leads to.

        2. 3

          and it’s possible that if a CVE had been created before the bug was fixed, it could be argued that as the behavior is UB it’s ipso facto a vulnerability.

          I’m not sure why discovering it before it’s fixed changes it’s nature wrt whether it’s a vulnerability or not.

          Some people run old software. It’s useful to know about vulnerabilities in old software that might be deployed out in the wild. I haven’t seen anyone suggest the 2020 designation nor the affected versions metadata to be at issue.

          What seems to be at issue is whether it’s a vulnerability at all, and (pre-supposing it is I suppose) the severity.

      2. 7

        I think what your post, and CVSS, don’t distinguish is the difference between the possible worst case (it’s UB and nasal demons), and the effect you get in practice — in this case it’s just arithmetic, not touching any UB-sensitive constructs.

        1. 12

          in this case it’s just arithmetic, not touching any UB-sensitive constructs.

          I think you’re making the same mistake I just pointed out. As I mentioned in my footnote, the code in question seems to be performing a signed integer overflow, which is UB.

          Being UB doesn’t necessarily mean that it’s a security vulnerability, and I never claimed otherwise. In practice, in this case it probably isn’t.

          But my point wasn’t that. My point was that the author didn’t even acknowledge that UB even existed or how it could lead to a security vulnerability. It would make me suspect that this possibility wasn’t even considered, if I didn’t know the author was such a prolific C developer.

          But I think what’s more important is how the audience of the post (which can include less-experienced C developers) can be induced into thinking that C is more straightforward / simple than it really is in terms of its security implications.

          Edit: perhaps you’re thinking that since it’s “just” an integer overflow and it’s not accessing an array out of bounds, that it’s not dangerous, even though it’s technically UB. That’s not how UB works and this is also part of my point.

          1. 10

            This is valid. For clarity (and I don’t think you’re disagreeing with this?) it would be on the reporter to provide evidence that the undefined behaviour here can be exploited as a security hole, though.

            Without at least a partial PoC this is just a bug with, at best, unexplored potential security implications. And certainly not deserving of a CVE with 9.8 severity.

            1. 6

              The depressing thing is that your evaluation of the implications is only valid for one version of one compiler on one architecture. As long as UB is present in the code, the behavior could change at any moment. It’s unlikely to become a security problem tomorrow, but it’s not impossible.

              1. 3

                I think a few commenters have mentioned that it’s actually impossible for the bug to become a security problem tomorrow because the bug has been fixed for years already.

                But in general, yes, your point would be completely valid if a bug exactly like that one were discovered today.

                Edit: to be clear, I don’t actually have a strong opinion as to what severity a CVE should have in the case of a potential but unproved security issue. I think this can be somewhat subjective, to an extent, unless it can be proved either way. It also depends on whether you tend to view things as “insecure unless proven secure” or “secure unless there are convincing reasons as to why it might be insecure”…

                1. 4

                  Yes, what’s depressing is the general principle that the reasoning in the post is invalid: yes, this is a bug, but it can only cause a relatively harmless behavior change (retries happening faster than the ridiculous timeout you specified). In the presence of “unlimited UB” how can you even reliably rate the severity of any UB bug?

                  1. 3

                    In the presence of “unlimited UB” how can you even reliably rate the severity of any UB bug?

                    It does seem theoretically unsolvable, but in practice I can think of 2 reasonable ways to do it, which I think are often practiced:

                    1. Either you prove one way or another, by developing (or trying to develop) an exploit, or by at least looking at the compiled code for the most important target platforms. In the case of not finding a security vulnerability, it still leaves a certain doubt regarding whether you just couldn’t do it (but others could), or whether it might be vulnerable in other platforms, other compilers, other compiler versions… but still, generally it gives you a pretty good idea of the severity of the issue.

                    2. Or, if you don’t do that, then at least try to make an educated “best guess”, based on experience and judgment. As an example, a bug in authentication or cryptography-related code is much more likely to be serious than, say, a bug in parsing or interpreting configuration options. Similarly, a bug in the HTTP parsing code of a popular HTTP daemon is much more likely to be serious than a bug in an obscure CLI tool that is rarely, if ever, accessed over the Internet. Or, a bug that can be triggered by default is more serious that one that can only be triggered if you change an uncommon or obscure option.

                    Sometimes it happens that a vulnerability is initially thought to be much less serious than it really is, and I think CVEs are changed accordingly (or new ones issued?) when it is later discovered that it’s more serious.

                    But sometimes it also happens the opposite: it is thought something is quite serious but then, it is later discovered that the code is unexploitable for some reason (in the major platforms and compilers, at least).

                    Edit:

                    what’s depressing is the general principle that the reasoning in the post is invalid: yes, this is a bug, but it can only cause a relatively harmless behavior change

                    Agreed.

                    1. 5

                      It does seem theoretically unsolvable, but in practice I can think of 2 reasonable ways to do it, which I think are often practiced

                      I would agree with these criteria and they seem like the crux of Daniel’s argument (pun unintended) that the result is relatively harmless behavior change. Neither he, nor the initial reporter, nor whomever filed this CVE, have been able to identify an attack vector (as seen in the Hackerone thread). Failing to have a PoC in hand, even from the reporter, Daniel relied on his intimate knowledge of the codebase and all the other security issues that have been found and determined this not to be a concern.

                      Given the attention this has gotten, I’m sure someone can come forward with a PoC if there is something to this. Absent that, it seems like based on both of your criteria this is not an actual issue, even if UB is handwavily impossible to bound.

                      1. 3

                        I still would have preferred if Daniel had acknowledged that a bug like this can be a security vulnerability. Instead, he seemed to imply that it cannot possibly be one, simply because it appears to be a harmless integer overflow. Like @wrs mentioned, this is flawed reasoning and leads to misconceptions.

                        I admit it’s a minor point, when you look at the entire situation, but I think it’s an important one.

                        I completely agree with Daniel and with you on everything else, at least, from my superficial understanding of the situation, although I don’t have strong opinions about some of these points, as I’m not very familiar with CVEs.

          2. 7

            I generally agree with the school of thought that UB is UB, and you just don’t let it happen, ever, because all bets are off, and C isn’t compiled for your CPU, but for the abstract machine of the C spec, and even if it “works” today it may not work tomorrow.

            However, if you need a practical answer whether this is actually a vulnerability in curl today, assuming specific compilers and optimizations, UB is not a mystery. Compilers don’t actively seek UB to backstab you, they have knowable circumstances where they make assumptions that exploit UB. You can take LLVM for example, and know what IR it will emit, and reason about its optimization passes, undefs, and poisons. And typically when there aren’t branches or indexing involved, it is a boring case of an unchecked mul without further consequences.

            So to be clear, I’m not advocating for a cavalier attitude of writing non-conforming C code by assuming it’ll work fine anyway. But when somebody reports a vulnerability, there needs to be a real-world way to exploit it, otherwise they’re reporting a theoretical soundness issue, which is something worth fixing, but not “9.8 critical”.

            1. 3

              I completely agree with your comment.

              As I said multiple times, I didn’t mean to suggest that this particular bug was a security vulnerability just because it was UB.

              I meant that since it’s UB, it can’t be easily dismissed as a non-vulnerability.

              But when somebody reports a vulnerability, there needs to be a real-world way to exploit it, otherwise they’re reporting a theoretical soundness issue, which is something worth fixing, but not “9.8 critical”.

              Yes, completely agreed.

          3. 2

            But my point wasn’t that. My point was that the author didn’t even acknowledge that UB even existed or how it could lead to a security vulnerability. It would make me suspect that this possibility wasn’t even considered, if I didn’t know the author was such a prolific C developer.

            It’s a good idea, when someone disagrees with you on something to do with UB, to try to see their point rather than just assume lack of knowledge/competence on their part.

            Especially when arguing that a bug should be treated as more critical due to involving UB, because it is effectively impossible to write a non-trivial C program free of UB. So anything that applies to this instance should then apply to basically every C program ever written.

            1. 6

              No offense, but I think you have missed my point, which I’ve made multiple times over several comments.

              • I have acknowledged Daniel’s competency.

              • I didn’t argue the bug should be treated as more critical.

              • I argued that he has implied that an integer overflow such as that one cannot possibly be a security problem. This is misleading and a C programmer should not think like that.

              • I’m pretty sure Daniel knows that. But his assertion, as written, is misleading.

              To be clear, once again: I am not saying that this particular bug is a security problem.

              1. 3

                I don’t see anywhere that he implied integer overflow in general “cannot possibly be a security problem”. He explained why in this particular case the overflow is extremely unlikely to trigger a significant security issue (i.e., because in the overflow case for this specific bug you’d have to specify a ludicrously huge retry timeout to begin with, and the consequence of the overflow is likely to be a much shorter retry interval).

                I do see where he speculates that whoever evaluated the bug for NVD saw “integer overflow” and assumed that it must therefore be of high/critical severity without looking into what, precisely, was overflowing or how it was used. But that is not downplaying all integer overflows, just saying – correctly! – that they need to be evaluated case-by-case with context.

                1. 6

                  I agree with most of your point, but:

                  He explained why in this particular case the overflow is extremely unlikely to trigger a significant security issue

                  He did not say the overflow is “extremely unlikely” to trigger a significant issue.

                  If he had said that, you wouldn’t have seen a single comment from me in this thread.

                  Instead, he said and I quote:

                  A bug, sure. Security problem? No.

                  And:

                  nobody at NVD engaged their brains nor looked at the “vulnerable” code or the patch that fixed the bug. Anyone that looks can see that this is not a security problem.

                  These are both very strong claims.

                  The second one is even demonstrably false, because you cannot simply look at the “vulnerable code” or the “patch” to determine whether a line of code that causes UB leads to a security vulnerability or not (unless it is otherwise contained, e.g. as in a sandbox or separate process).

                  You’d actually have to look at the compiled code, under all relevant platforms, compilers and compiler versions, to determine whether that bug leads to a security problem.

                  So again, he seems to imply that it’s possible to exclude the possibility of a security vulnerability in UB-causing code by doing the analysis he’s talking about. That’s not how it works.

                  I’m also pretty sure he knows that. I just think he worded his article more strongly than he intended, possibly because of the (greatly deserved) outrage (although this is just a guess).

                  1. 3

                    He did not say the overflow is “extremely unlikely” to trigger a significant issue.

                    If he had said that, you wouldn’t have seen a single comment from me in this thread.

                    As I understand it, your criticism of his “Security problem? No.” comment boils down to the fact that a hypothetical compiler, on encountering the potential integer overflow, might hypothetically decide to launch_the_missiles() or otherwise do something with dangerous side effects.

                    And yet nobody has demonstrated a widely-used compiler actually doing something dangerous with this case. The fact that a hypothetical compiler can hypothetically do anything it wants with UB is meaningless; what matters is what actual real-world compilers do with actual real-world code. And actual compilers have to operate in a real world where, as I already mentioned, it’s effectively impossible to write non-trivial C programs without UB, so if they were launching the missiles every time there wouldn’t be much of a world left at this point.

                    Which is why A) it’s perfectly reasonable for Daniel to describe it the way he did, B) the CVSS score is bad, C) I return to my original point that it’s bad to assume lack of knowledge/competence as an automatic first response to someone with a different perspective on UB than you have.

                    If you want to continue to split hairs about the exact wording you wanted him to use to describe this, feel free, but I’ve made my point and intend to move on.

                    1. 5

                      I took a little time to look at real issues that have been found with real compilers, that demonstrate my point and I think are all counterexamples to your claims.

                      Here’s an article that shows very surprising behavior, i.e. a real-world compiler causing an unexpected crash in the compiled program, simply due to an integer overflow.

                      GCC undefined behaviors are getting wild:

                      the i >= 0 && i < sizeof(tab) condition should be enough to take care of it, whatever crazy value it becomes, right? Well, I have bad news […]

                      nevertheless the execution violates the gate condition, spout a non-sense lie, go straight into dereferencing tab, and die miserably.

                      Here’s another article, with a couple of demonstrations of surprising UB-related issues with a real compiler that are also counterpoints to your comment (one of them also being an integer overflow).

                      Shocking Examples of Undefined Behaviour:

                      Example1 : A simple finite loop turning into infinite loop

                      Example 2: […] In this example, EraseAll is never called, but when we run this program with Clang-10.0.0 x86-64, it prints “Disaster Ahead”. Which also means it will run system(“rm -rf /”) if we uncomment it.

                      (That article was in C++, but similar issues exist in C, as UB works under the same principle).

                      Also, an LWN article explaining issues with signed overflow, again, talking about real compilers. Signed overflow optimization hazards in the kernel:

                      All systems running Linux are twos complement, so we really should not worry about clauses in the C standard designed to handle the wider variety of arithmetic that was available a few decades ago, right? Unfortunately, wrong. The C compiler can and does make use of undefined behavior when optimizing. […] Therefore, this optimization has significantly changed the program’s behavior.

                      Another LWN one. Who’s afraid of a big bad optimizing compiler?:

                      […] For these developers and maintainers, a significant level of fear of the big bad optimizing compiler is a very healthy thing, and the rest of us should hope that they continue to maintain an appropriate level of fear. […] we should continue to expect increasingly aggressive compiler optimizations over time.

                      The next one in the LLVM blog is a really great article that explains all these issues in detail with quite a few examples and it also talks about real-world software.

                      What Every C Programmer Should Know About Undefined Behavior:

                      While this is intentionally a simple and contrived example, this sort of thing happens all the time with inlining […] a variety of local optimizations can kick in, which change the behavior of the code. This is both perfectly valid according to the standard, and important for performance in practice.

                      Undefined Behavior and Security Don’t Mix Well

                      […] This problem has bit many projects (including the Linux Kernel, OpenSSL, glibc, etc) and even led to CERT issuing a vulnerability note against GCC (though my personal belief is that all widely-used optimizing C compilers are vulnerable to this, not just GCC).

                      […] As it turns out, integer overflow is a security problem for many reasons.

                      The next one was the Linux kernel security vulnerability I was referring to, which was in 2009 and as I recall, it was extremely surprising at the time for almost everyone, as it was one of the first (if not the first) widely-known examples of a compiler seemingly, and surprisingly, causing a security vulnerability due to optimizations exploiting undefined behavior.

                      Fun with NULL pointers:

                      This is where the next interesting step in the chain of failures happens: the GCC compiler will, by default, optimize the NULL test out. The reasoning is that, since the pointer has already been dereferenced (and has not been changed), it cannot be NULL. So there is no point in checking it. Once again, this logic makes sense most of the time, but not in situations where NULL might actually be a valid pointer.

                      I’m pretty sure there are many, many more real examples such as these ones, as they were really easy to find (except the last one, as I was looking specifically for it and didn’t remember the details), but I think I’ve already gotten my point across pretty well.

                      Edit: provided more quotes.

                      Edit 2: removed duplicate LWN article.

                      Edit 3: it wasn’t a duplicate article, so I readded it. Also added the article titles.

                      1. 5

                        The issue here is there is no number of examples from other software that can make the case for this instance of UB in this piece of software being as severe an issue as you seem to want.

                        This is a user-supplied command-line parameter parsed as an integer, and the actual potential overflow was multiplying it by 1000 to convert from seconds to milliseconds. The fix was to use an alternative parse that caps the returned value in a way that prevents the potential overflow.

                        Yes, UB can be tricky, and yes, UB can cause unexpected results. But to support the amount of fighting over minor semantics you’re doing here, the burden is on you to demonstrate that this particular code in this particular version of curl, when compiled with a reasonably popular compiler, will replace that block with launch_the_missiles() or equivalent dangerous/unexpected code. Until you do, I will trust Daniel’s analysis of the exploitability of this potential overflow.

                        1. 5

                          The issue here is there is no number of examples from other software that can make the case for this instance of UB in this piece of software being as severe an issue as you seem to want.

                          I do not “want” the issue to be severe and I never tried to argue it was. I said multiple times that I don’t think it’s severe, and even said it as a reply to a comment of yours, which you seem to have forgotten.

                          Yes, UB can be tricky, and yes, UB can cause unexpected results.

                          I’m glad you are acknowledging this. Daniel did not acknowledge this. And you also didn’t seem to be acknowledging this before. In fact you said:

                          And yet nobody has demonstrated a widely-used compiler actually doing something dangerous with this case

                          … where “this case” was, as I understood, a potential integer overflow. Which is why I provided multiple examples contradicting your statement, i.e. where widely-used compilers (i.e. gcc and clang) have done dangerous things due to UB (like introducing security vulnerabilities, causing a crash that wouldn’t be there otherwise, or causing code that wasn’t being called anywhere, to be called).

                          But to support the amount of fighting over minor semantics you’re doing here

                          It’s not minor semantics, it’s an important issue that should be acknowledged. Integer overflows can lead to security vulnerabilities.

                          Entire series of blog posts and articles have been written about this by LLVM developer(s), LWN editors and many others. It’s an issue that has already affected multiple high-profile projects like the Linux kernel, glibc and OpenSSL.

                          Daniel was implying that this integer overflow cannot lead to a vulnerability, and he’s likely to be right (I never argued otherwise), but his assertions as written do not support the proper reasoning for why it cannot. Instead, he seems to imply that it cannot lead to a vulnerability because it looks like a harmless integer overflow. Not that it’s unlikely to lead. That it cannot. This is a flawed assertion. Not acknowledging that it can lead to a vulnerability is misleading. It leads to misconceptions about the C language, C compilers and software security.

                          As I said before in another comment, it is a minor issue when considering the entire situation, but it is an important one, especially if you have any interest at all in educating your fellow peers who might be reading the post (most of which being less experienced than Daniel, presumably).

                          the burden is on you to demonstrate that this particular code in this particular version of curl, when compiled with a reasonably popular compiler, will replace that block with launch_the_missiles() or equivalent dangerous/unexpected code.

                          It’s really not my burden, I assure you :)

                          And what’s even more, I wouldn’t even argue that it’s David’s burden to prove that it’s unexploitable, as that seems quite unreasonable for any maintainer, since it can require a huge amount of highly-specialized work.

                          Instead, I agree with several other people who said that the burden should probably be on the person/people who assigned the high severity to the CVE.

                          Until you do, I will trust Daniel’s analysis of the exploitability of this potential overflow.

                          I’m glad you do! I do too, believe it or not, a million times more than my own extremely superficial analysis!

                          But again, for the millionth time, I did not argue that this potential overflow is exploitable. That has never been my point.

                          I suspect that you haven’t, or hadn’t, properly understood my arguments and that instead, you have been attacking a straw man…

                          1. 5

                            Daniel did not acknowledge this. And you also didn’t seem to be acknowledging this before.

                            He doesn’t need to “acknowledge” that UB in general can be a source of unexpected behavior or serious unintended consequences, because he never denied that, and I never denied it either.

                            The claim at hand is that this exact precise specific instance (making no claim with regard to any other instance) of this exact precise specific type (making no claim with regard to any other type) of potential UB in this exact precise specific segment of code (making no claim with regard to any other segment of code) in this exact precise specific version (making no claim with regard to any other version) of this exact precise specific piece of software (making no claim with regard to any other piece of software) called “curl”… is not a security vulnerability.

                            That’s the claim Daniel made. He didn’t use such agonizingly precise language because he’s a human being and he relies on other human beings to read his words in good faith and with the principle of charity, and conclude that when he says “Security problem? No.” in this post he is referring to this exact precise specific, etc. That also is the most obvious reading of the statement given the surrounding context, which is entirely about the specific instance in that specific version of curl.

                            You are the only one who has argued as if he (or I) made some type of general statement or denial about all UB, or all integer overflows. He (and I) never made any such general statement or denial. He made, again, the specific narrow statement that this particular instance in curl was not a security issue. Nobody else seems to have found a need or a reason to interpret it as anything other than a specific narrow claim. This strongly suggests that you should reconsider whether he was making any type of broader statement about UB or overflow in general, and then reconsider whether there is anything that you need to so vociferously argue with.

                            And this is why I say that no number of anecdotes from other software will work here, because all of your presented anecdotes are about overflow and UB in general rather than analyzing this specific instance of overflow in curl.

                            Thus I will repeat myself: if you wish to claim that this specific overflow in curl is a security vulnerability, the burden of proof is on you to demonstrate in what matter it is a security vulnerability. Presenting anecdotes about other instances of overflow or other forms of UB in other software does not prove that this specific overflow in curl was a security vulnerability.

                            Now. Please, either move on from this, or actually engage with what you’re being told. Continuing to say that people deny or won’t “acknowledge” the general case is a strawman.

                            1. 3

                              He doesn’t need to “acknowledge” that UB in general can be a source of unexpected behavior or serious unintended consequences

                              I didn’t mean that he needed to acknowledge that (or at least, not just that). What I really meant is that he didn’t acknowledge that this precise bug was UB. Since UB “can be tricky” (your words) and “cause unexpected results” (your words), you can’t say that that precise piece of code is definitely secure just because it looks like a harmless integer overflow and that everyone can see it’s secure just by taking a look at the code, which is what Daniel said.

                              So all of your suggestions that I’m complaining about you or Daniel not making some type of claim about UB in general or any other thing in general, is missing the point completely. I’m referring to that specific piece of code only and in fact, I am falsifying his claims as written (which I’m guessing is not how he meant to write, but many others won’t be able to guess that).

                              Thus I will repeat myself: if you wish to claim that this specific overflow in curl is a security vulnerability

                              For the millionth time, I do not. I have said this several times to you already, and others.

                              There’s no need for you to “repeat yourself” attacking a strawman.

                              Edit: clarified a point.

                              1. 3

                                What I really meant is that he didn’t acknowledge that this precise bug was UB.

                                It’s an integer overflow and he acknowledged that. He doesn’t need to add further explanation because, again, he is a human writing for other humans who will read his words charitably.

                                Nobody else who read his post seems to think he somehow denied it was UB or needed to add explicit warnings and clarifications and explanations. Only you. Which, for like the third time now, should probably be a warning sign to you that the problem is not with his words but with how you chose to read them.

                                1. 1

                                  It’s an integer overflow and he acknowledged that.

                                  But he did not acknowledge that it was a signed integer overflow, which is UB.

                                  A signed integer overflow in C can be very different from an unsigned integer overflow in terms of its security implications, since one is UB and the other is not.

                                  In fact, anyone who reads the explanation will think it was an unsigned integer overflow, because when he talks about the integer overflowing, he implies that it wraps around into a positive integer, not a negative one.

                                  Unsigned integer overflows are not UB. Therefore, they are not as dangerous. Therefore, you’d think the integer overflow in that bug would be much more harmless than it really can be.

                                  Do you understand that?

                                  1. 1

                                    Originally you said your issue was with this statement:

                                    A bug, sure. Security problem? No.

                                    Then you walked it back and said you weren’t disagreeing with him on the security implications, and now you’ve flipped to claiming that the problem is he didn’t specifically include a statement that signed integer overflow is UB.

                                    I can’t meaningfully engage when the claim you’re making shifts so much from one comment to the next.

                                    1. 1

                                      Then you walked it back and said you weren’t disagreeing with him on the security implications

                                      I don’t disagree with his assessment that it’s unlikely to be a security problem. I still, and always have disagreed with him saying “Security problem? no”, because that implies that it’s definitely not a security problem, which is an unsubstantiated claim.

                                      and now you’ve flipped to claiming that the problem is he didn’t specifically include a statement that signed integer overflow is UB.

                                      If he had included such a statement it would have been much better, for several reasons.

                                      But he didn’t have to say that, as long as he hadn’t made such strong statements as he did.

                                      I can’t meaningfully engage when the claim you’re making shifts so much from one comment to the next.

                                      It has never shifted. What might have shifted is your understanding of what my claims are. This is evident because I had to repeat several times the same exact argument because you were still thinking I was saying the opposite.

                    2. 5

                      The compiler behavior, of real compilers (not hypothetical ones) is, in some cases, a lot more complex, unintuitive and surprising than what you just described.

                      Almost every C programmer has misconceptions about what real compilers do. Even Linus Torvalds has been surprised in the past by compiler behavior, which (IIRC) is why the kernel enables some options to make optimizations less aggressive (if I’m not mistaken).

                      In fact, I think everyone, except the gcc developers, was surprised when it was first discovered that a safety check in a Linux kernel function had been automatically removed by gcc because of UB.

                      Since then, even more surprising behavior has been found in real code, although I don’t recall the details ATM.

                      If you or someone else want to stick your head in the sand that’s fine, but then don’t be surprised when such a bug bites you in the ass… :)

        2. 4

          Just to add to my point, for those who haven’t seen it, the excellent Falsehoods programmers believe about undefined behavior article demonstrates one of the points I was making.

          The associated Lobste.rs thread is also well-worth reading.

    4. 5

      AFAIK you can fill this out: https://cveform.mitre.org/

      And request that the CVE be rejected, or at least recategorized/rescored.

      Anyone ever try this?

      1. 5

        Yes. It is… Its own form of insanity. Daniel has a few blogpost exploring that.

        1. 2

          Yeah, just to be super clear, I think the CVE system is deeply flawed in a number of ways.

    5. 3

      The CVE says

      Known Affected Software Configurations cpe:2.3:a:haxx:curl:7.65.2:::::::*

      Curl on debian testing is 8.2.1

      So maybe they are just backfilling historical data

      1. 4

        Wait, you can do that? I.e. create obsolete CVEs from unpatched software, that’s since been patched?

        1. 1

          It sorta makes sense that this would be possible - there are lots of reasons to want to discuss a vulnerability that’s already been patched, for example if the patch hasn’t been widely deployed yet.

          Obviously in this case it’s silly, because the vulnerability doesn’t exist.

          1. 1

            OK. I don’t know a lot about how these things are registered.

            Does it happen often? I got the impression that this is something that’s very rare (i.e. retroactively dating CVEs).

    6. 2

      KeePassXC had a similar experience recently where someone didn’t understand the attack vector of KPXC and submitted false CVEs.