4 ms·

The original secp256k1 developer Russell O’Connor who was hit by the bug (was on HN [0]) [1] said he rebuilt every package in his system after the bug was ident

The original secp256k1 developer Russell O’Connor who was hit by the bug (was on HN [0]) [1] said he rebuilt every package in his system after the bug was identified, and found only 10 lines of code that were miscompiled. Also, note that the bug was found during an attempt to add more test cases, pre-existing code in secp256k1 was not affected. > Three lines are tests. All of the lines could be rewritten as a comparison to 0. None of the lines looked that serious. I am not sure which one is the worse: the reduced message integrity code(?) from some ARCFOUR implementation or the something something from an ATM driver? Two unusual conditions are needed to trigger it... > * at least one of the compared byte arrays is constant and has a zero byte in position 0, 1, 2, or 3, and > * the result of the memcmp isn't immediately used in a "== 0" or "!= 0" test (or equivalently "if(memcmp(...))" or "if(!memcmp(...))"). > In particular the second condition makes this bug pretty rare and explains why it's mostly hit in non-inlined memcmp wrappers. (But in our case we hit it with a "<" comparison. ) Looks like a critical bug, but doesn't look like a conspiracy. [0] https://news.ycombinator.com/item?id=24636326 https://news.ycombinator.com/item?id=24636326 [1] http://r6.ca/blog/20200929T023701Z.html http://r6.ca/blog/20200929T023701Z.html

moonchild 6y ago
Or, alternately, it's a conspiracy which is intended to have very tight coverage; it's very difficult to detect, if most code slips it by.
- segfaultbuserr 6y ago
  > it's very difficult to detect, if most code slips it by. What would be the point if it has missed nearly every target? Based on the field survey by Russell O’Connor, no major crypto project or server project has been affected. The only security victim is a RC4-HMAC implementation for Kerberos 5, which has very limited uses - for Windows 2000, and deprecated since a long time ago. The only possible explanation would be either, 1. A long-term time bomb, intended to hit a big fish in the future, in a random, non-specific way. 2. Targeted attack (which doesn't make much sense, if you have enough exploitation capabilities to launch many types of targeted attacks already, why bother to leave a public record in GCC?).
  - moonchild 6y ago
    Sure. I don't think it's particularly likely to have been a conspiracy. Just speculating. If I were to try to put an illicit backdoor in a compiler, I would try and make damned sure it's not traceable to me. It's a very subtle thing. You have to submit a patch with an improvement (or, at least, an apparent one) to the compiler, which also contains your backdoor. You have to ensure said patch doesn't immediately cause test failures in gcc, or in projects using gcc. If you can manage that, though, it'd be very difficult to prove that you were responsible, which is why I think the targeted attack is entirely plausible.
    - HourglassFR 6y ago
      > If you can manage that, though, it'd be very difficult to prove that you were responsible, which is why I think the targeted attack is entirely plausible. So the only argument you have to suggest it might be an intentionally introduced bug is that it doesn't look like one… I understand the sentiment but this is clearly a ridiculous line of reasoning.
      - moonchild 6y ago
        The patch that introduced the bug is at [1]. Does it look to you like it introduced a bug? Granted, you're not a gcc developer—neither am I—but the gcc developers didn't think so either. Bugs are accidentally introduced all the time, true. But I don't think it's fair to say that this is a ridiculous line of reasoning. 1. https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=14b7950f126f84fa585e3a057940ff10d4c5b3f8;hp=1b1e13dbde7f3eef0f8356af05c5de1fb46cb31b https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=14b7950f12...
deleted 6y ago
[deleted]
qwertox 6y ago
For those interested, ATM doesn't refer to an automated teller machine, but to the UPD98401 high-performance Asynchronous Transfer Mode (ATM) controller. https://www.digchip.com/datasheets/parts/datasheet/322/UPD98401.php https://www.digchip.com/datasheets/parts/datasheet/322/UPD98...

moonchild 6y ago

Or, alternately, it's a conspiracy which is intended to have very tight coverage; it's very difficult to detect, if most code slips it by.

segfaultbuserr 6y ago
> it's very difficult to detect, if most code slips it by. What would be the point if it has missed nearly every target? Based on the field survey by Russell O’Connor, no major crypto project or server project has been affected. The only security victim is a RC4-HMAC implementation for Kerberos 5, which has very limited uses - for Windows 2000, and deprecated since a long time ago. The only possible explanation would be either, 1. A long-term time bomb, intended to hit a big fish in the future, in a random, non-specific way. 2. Targeted attack (which doesn't make much sense, if you have enough exploitation capabilities to launch many types of targeted attacks already, why bother to leave a public record in GCC?).
- moonchild 6y ago
  Sure. I don't think it's particularly likely to have been a conspiracy. Just speculating. If I were to try to put an illicit backdoor in a compiler, I would try and make damned sure it's not traceable to me. It's a very subtle thing. You have to submit a patch with an improvement (or, at least, an apparent one) to the compiler, which also contains your backdoor. You have to ensure said patch doesn't immediately cause test failures in gcc, or in projects using gcc. If you can manage that, though, it'd be very difficult to prove that you were responsible, which is why I think the targeted attack is entirely plausible.
  - HourglassFR 6y ago
    > If you can manage that, though, it'd be very difficult to prove that you were responsible, which is why I think the targeted attack is entirely plausible. So the only argument you have to suggest it might be an intentionally introduced bug is that it doesn't look like one… I understand the sentiment but this is clearly a ridiculous line of reasoning.
    - moonchild 6y ago
      The patch that introduced the bug is at [1]. Does it look to you like it introduced a bug? Granted, you're not a gcc developer—neither am I—but the gcc developers didn't think so either. Bugs are accidentally introduced all the time, true. But I don't think it's fair to say that this is a ridiculous line of reasoning. 1. https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=14b7950f126f84fa585e3a057940ff10d4c5b3f8;hp=1b1e13dbde7f3eef0f8356af05c5de1fb46cb31b https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=14b7950f12...

deleted 6y ago

[deleted]

qwertox 6y ago

For those interested, ATM doesn't refer to an automated teller machine, but to the UPD98401 high-performance Asynchronous Transfer Mode (ATM) controller. https://www.digchip.com/datasheets/parts/datasheet/322/UPD98401.php https://www.digchip.com/datasheets/parts/datasheet/322/UPD98...