And I think people should now look at all oddities with Valgrind. Since that is how the issue got discovered. And then look at the problematic library and look for similar outliers of fake personas taking over a project.
It seems it is common practice for people to ignore these errors.
Do you remember the Debian openssl flaw? Okay, it's almost 20 years old now, so you may have forgotten, or you could be too young, I don't know. But it was caused by someone attempting to fix an oddity found by valgrind.
There was an upstream OpenSSL bug there: they depended on reading from uninitialized memory to add entropy and thus increase startup speed of their RNG. But reading from uninitialized memory is undefined behavior, it's not guaranteed to add any entropy and should always be treated as a security bug. The Debian maintainers tried to fix the bug, but screwed up the fix. They should have reported the bug upstream, not just made their own fork.
My memory is fuzzy. In that case, I'd blame the OpenSSL devs if the report wasn't a patch with the (non-working) "fix". Even if it was, they should have accepted the bug & rejected the patch.
I remember this and the like is a good write-up, thanks for the link. I have see things like this over the past 30+ years. So a couple of Items to add:
* Comment the hell out of hidden logic like this. Explain why nor what :)
* Better yet, even though that uninitialized buffer helped with performance. These days it would be better to take the hit and add a random initialization of that buffer. Maybe read /dev/urandom or some other thing.
You do not know who will come along after you, so try and make things explicit.
Valgrind will tell you about memory leaks and won't always behave the way it did here when there's a backdoor. In this case it just so happened that valgrind was throwing errors because the stack layout didn't match what the exploit was expecting. Otherwise valgrind would have probably worked without issues.
I am also curious, and if something like asan would also have found it? It seems social engineering was used to get MS to stop fuzzing the library for malicious code, so if the malicious party expected the valgrind behavior they might have removed it as well.
Which to me is a very carefully orchestrated thing. You don't just spend 2 years of your life doing that. No loner would pre-plan this to such an extent and create sockpuppet accounts for all this.
That's because you're a normal, well adjusted person.
Consider TempleOS[1] which was created by a programmer having a series of manic episodes which he believed was God's instruction to create 640x480 pixels of perfection.
He spent the rest of his life on this.
People vastly underestimate the tenacity of individual fixated people: so much so that in the physical world victims usually feel isolated by their peers who just don't believe the degree of effort they stalker will actually go to.
TempleOS feels a little different because Terry was fairly well-known in the community and didn't try to hide his identity. I'm pretty sure he went to conferences and has met with actual people who could verify his identity.
I haven't seen proof that Jia Tan is a real person and to me that's the most malicious part of the attack. I'm pretty confident that whoever is hiding behind the Jia Tan identity is a well adjusted individual (or group) and knows exactly what they're doing. It feels far too coordinated and careful to chalk up to a psychotic episode or manic behavior.
Thanks, Microsoft, I like Azure now.