Comment by segfaultbuserr | Hacker News Reader

Comment by segfaultbuserr | Hacker News Reader

Parent Full thread

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

[1] http://r6.ca/blog/20200929T023701Z.html

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/UPD98...

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.

> 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?).

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.

> 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.

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=14b7950f12...

Reply on news.ycombinator.com