> We hit this bug in a test case in secp256k1, the cryptography library used in Bitcoin Core.
That smells fishy. Is it possible the compiler introduces an intentional bug?
That smells fishy. Is it possible the compiler introduces an intentional bug?
> 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.
https://www.digchip.com/datasheets/parts/datasheet/322/UPD98...
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?).
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.
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.
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...
The miscompilation of the implementation of draft-brezak-win2k-krb-rc4-hmac-04.txt seemed interesting to me and potentially of a security concern. They looked to me like they were potentially significantly reducing the length of the message integrity check in an authentication protocol.
https://github.com/heimdal/heimdal/blob/7ae2dfd853c87f9cbecb...
https://github.com/heimdal/heimdal/blob/7ae2dfd853c87f9cbecb...
https://github.com/heimdal/heimdal/blob/7ae2dfd853c87f9cbecb...
Though its hard to say for sure without even a passing familiarity with that protocol or its implementation. If you wanted to go vulnerability hunting, however, that is where I'd start.
That said, even if there is a bug that is no evidence that it would have been intentional. Sadly, an intentionally introduced bug could be absurdly subtle. One of the downsides of software bugs being relatively common is that you can't be sure if a bug was intentional or not... and at the same time it's silly to assume one was intentional because we know that real bugs are so common.
It's long been my view that if you're not occasionally finding compiler bugs -- even in somewhat older compilers-- you're just not testing hard enough. They've become more rare but are not so rare that a single developer comprehensively testing a small library won't eventually find one (or more). (Libsecp256k1 is ~9,964 lines of code and ~8,235 lines of test code).
Many other cases found by Russell's system wide recompilation were also in test cases or were otherwise pretty obviously not that big of a deal.
Fortunately, this ancient and deprecated [0] authentication protocol from Windows 2000 is uncommon today. AES-HMAC is used since Windows Vista.
[0] https://web.mit.edu/kerberos/krb5-devel/doc/admin/enctypes.h...
Even this is not welcomed on HN nowadays?
I agree with his assessment that it's probably just someone's mistake. I also personally wouldn't have worded quite that way, even if technically correct (incompetent is fairly harsh wording in English). I don't think it's worth down voting over.
Sometimes you just have a problem that's hard to wrap your head around and you think you found a way to make code faster that just isn't so.
Now the issue is better understood and we may end up with a couple good tests to prevent future regressions.
Also, I would guess gcc does code reviews. If so, gcc seems to be full of incompetent programmers, making it a miracle that this thing can even compile hello world. I don’t think that’s the case.
> If so, gcc seems to be full of incompetent programmers
Are you bristling at a word that looks like an insult and then ignoring what I'm actually saying? I specifically said you can be incompetent at a particular thing at a particular moment in time and that it is not a summary of you in general!
I'd say that pretty much everyone is completely incompetent when it comes to correctly implement a complicated piece of software like GCC. OTOH, the people who develop GCC are incredibly competent at what they do because the compiler does insanely complicated things the vast majority of the human race would struggle to comprehend and, yet, its surprisingly correct, with the occasional bug and confusion here and there.
We all work at the limits of our wits. Right now I'm waiting for a timeout so I can continue to test a hypothesis. If I am lucky, I'll be right and the system will malfunction in the way I expect it to. I'd say my chances at this point are 50/50.
> with the occasional bug and confusion here and there
And the point of this thread was talking about a big batch of bugs, the opposite of "occasional".
#if defined(__GNUC__) && defined(__GNUC_PATCHLEVEL__) && \
(((__GNUC__ == 9) && (__GNUC_MINOR__ <= 3) || \
(__GNUC__ > 9)))
His name and hotmail email is associated in git with various cryptography projects including openssl.
Look now the history "ends" at a different commit: https://gcc.gnu.org/git/?p=gcc.git;a=search;h=5828c09abe00cc...
Your links shows commits 2016-2018
https://www.theregister.com/2020/04/23/gcc_openssl_vulnerabi...
[0] https://www.theregister.com/2020/04/23/gcc_openssl_vulnerabi...
FandangoRanger made a comment, said it can be a backdoor. And rurban made a comment, said it's unlikely to be a backdoor. Both have been downvoted. I guess the hivemind is fair enough...
Not necessarily so. Perhaps the hivemind is not interpreting the question as a binary one. For example, the downvote for "Reflections on trusting trust?" can be result from the cliche fatigue.