Hacker News Reader

Comment by shp0ngle | Hacker News Reader

I didn't realize it was a Microsoft engineer that works on Azure Postgres that found the issue.

Thanks, Microsoft, I like Azure now.

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.

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.

The idea is not "valgrind will detect all tomfoolery". The idea here is "if valgrind detects something it may be an indication of tomfoolery.'

Exactly.

Also remember this

>> odd valgrind complaint in automated testing of postgres

I would imagine compiling a list of odd complaints may yield something , or nothing at all.

> the stack layout didn't match what the exploit was expecting.

What does that mean? Why is the exploit expecting something from the stack layout and why does valgrind complain?

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.

[1] https://en.m.wikipedia.org/wiki/TempleOS

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.

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.

https://blogs.fsfe.org/tonnerre/archives/24

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.

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.

IIRC, they did report the bug, and it was rejected.

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.

no - it is a PostgreSQL PGDG engineer hired by MSFT.. I cannot stand this spin

Reply on news.ycombinator.com