Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The xz sshd backdoor rabbithole goes quite a bit deeper

twitter.com

Post reply on HN
Print view View original

171–180 of 310 posts

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#171

Post by cesarb »

ThePowerOfFuet wrote: post #159
orbital-decay wrote: post #136

Earlier quoted context omitted.

That's why I mentioned the recent story. [0] [1] "Apple doesn't know" when the chain uses an internal backdoor in Apple hardware is a... stretch. And the chain gives the strong vibes of corporate-style development, with all its redundancy and mismatch between two parts. It's not alchemy, really. [0] https://securelist.com/operation-triangulation-the-last-hard... [1] https://news.ycombinator.com/item?id=38783112 - HN…

Re the secret knock in the Apple silicon, a friend of mine once said "that's how you lose the NOBUS on a backdoor", and I think they were absolutely right. The one thing which most leads me to believe this was an intentional backdoor? The S-boxes.

> The one thing which most leads me to believe this was an intentional backdoor? The S-boxes.

If you look at that HN discussion, you'll find a link to a Mastodon post from an Asahi Linux developer explaining that these "S-boxes" are actually an ECC calculation, and that the registers are probably cache debug registers, which allow writing directly to the cache bypassing the normal hardware ECC calculation, so you have to do the ECC calculation yourself if you don't want a hardware exception caused by an ECC mismatch on read (of course, when testing the cache, sometimes you do want to cause an ECC mismatch, to test the exception handling).

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#172

Post by orbital-decay »

ThePowerOfFuet wrote: post #159
orbital-decay wrote: post #136

Earlier quoted context omitted.

That's why I mentioned the recent story. [0] [1] "Apple doesn't know" when the chain uses an internal backdoor in Apple hardware is a... stretch. And the chain gives the strong vibes of corporate-style development, with all its redundancy and mismatch between two parts. It's not alchemy, really. [0] https://securelist.com/operation-triangulation-the-last-hard... [1] https://news.ycombinator.com/item?id=38783112 - HN…

Re the secret knock in the Apple silicon, a friend of mine once said "that's how you lose the NOBUS on a backdoor", and I think they were absolutely right. The one thing which most leads me to believe this was an intentional backdoor? The S-boxes.

I don't believe it's intentional for the reason you mentioned. Although it could theoretically be like that for plausible deniability, Apple's reputation is definitely more valuable than one patchable backdoor of god knows how many others. But debug backdoor is still a backdoor.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#173

Post by bilekas »

sho_hn wrote: post #91
bannable wrote: post #71

Earlier quoted context omitted.

What do you mean by "package managers not taking source from the right place"?

I assume they are advocating for package managers to preferably grab signed git tags from repositories rather than download tarballs. The backdoor relied on the source in the tarballs being different from the git tag, adding additional script code. This is common for projects that uses GNU autotools as build system; maintainers traditionally run autoconf so that users don't have to and ship the results in the tarball…

Correct. The onus should be now be on the package delivery to provide transperant packages maybe? Maybe add the extra step of pulling instead of trusting the push from maintainers? It's just an extra step the might get more eyes. All said, even in hindsight I wouldn't have called this one out.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#174

Post by vinay_ys »

orbital-decay wrote: post #119
ufmace wrote: post #14

The weird thing about this one is how it seems super professional in some ways, and rather amateur in others. Professional in the sense of spending a long time building up an identity that seemed trustworthy enough to be made maintainer of an important package, of probably involving multiple people in social manipulation attacks, of not leaking the true identity and source of the attack, and the sophistication and ob…

You probably have too high expectations when you hear the "state-sponsored" part. Every large organization will inevitably end up like any other. They also have bureaucracy, deadlines, production cycle, poor communication between teams, the recent iOS "maybe-a-backdoor" story also shows that they don't always care about burning the vulnerabilities because they amassed a huge pile of them.

state-sponsored organizations in this space could be usually military-like organizational structure that has people with dedication and motivation unlike corporate workers. command structure can mean less bureaucracy (can also mean more bureaucracy too in some ways) when it is directly aligned with their mission. national patriotism motivations mean they are more dedicated and focused than a typical corporate worker. so yeah, there would be quality differences.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#175

Post by varjag »

ufmace wrote: post #14

The weird thing about this one is how it seems super professional in some ways, and rather amateur in others. Professional in the sense of spending a long time building up an identity that seemed trustworthy enough to be made maintainer of an important package, of probably involving multiple people in social manipulation attacks, of not leaking the true identity and source of the attack, and the sophistication and ob…

Different departments.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#176

Post by TacticalCoder »

bdd8f1df777b wrote: post #161
rav wrote: post #109

Earlier quoted context omitted.

> The backdoor relies on sshd being patched to depend on libsystemd to call sd_notify I remember when we added sd_notify support to our services at work, I was wondering why one would pull in libsystemd as a dependency for this. I mean, there's a pure-Python library [1] that basically boils down to: import os, socket def notify(state=b"READY=1"): sock = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) addr = os.geten…

> With proper error handling, that's about 50 lines of C code. Writing proper error handling in C is a very tedious and error prone task. So it doesn't surprise me that people would rather call another library instead.

> So it doesn't surprise me that people would rather call another library instead.

Which shall be harder to justify now: "You're calling a gigantic library full of potential security holes just to call one function, to save writing a few lines of code, are you trying to JIA TAN the project?".

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#177

Post by vinay_ys »

orbital-decay wrote: post #172
ThePowerOfFuet wrote: post #159

Earlier quoted context omitted.

Re the secret knock in the Apple silicon, a friend of mine once said "that's how you lose the NOBUS on a backdoor", and I think they were absolutely right. The one thing which most leads me to believe this was an intentional backdoor? The S-boxes.

I don't believe it's intentional for the reason you mentioned. Although it could theoretically be like that for plausible deniability, Apple's reputation is definitely more valuable than one patchable backdoor of god knows how many others. But debug backdoor is still a backdoor.

Very large companies are definitely at the mercy of governments. Just look at how they are bending over backwards to comply with DMA etc. So, it is not at all inconceivable that they are forced to put backdoors into their product by the governments.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#178

Post by varjag »

vinay_ys wrote: post #174
orbital-decay wrote: post #119

Earlier quoted context omitted.

You probably have too high expectations when you hear the "state-sponsored" part. Every large organization will inevitably end up like any other. They also have bureaucracy, deadlines, production cycle, poor communication between teams, the recent iOS "maybe-a-backdoor" story also shows that they don't always care about burning the vulnerabilities because they amassed a huge pile of them.

state-sponsored organizations in this space could be usually military-like organizational structure that has people with dedication and motivation unlike corporate workers. command structure can mean less bureaucracy (can also mean more bureaucracy too in some ways) when it is directly aligned with their mission. national patriotism motivations mean they are more dedicated and focused than a typical corporate worker.…

Patriots for the most part suck at coding as much as everyone else.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#179

Post by AndyMcConachie »

ufmace wrote: post #14

The weird thing about this one is how it seems super professional in some ways, and rather amateur in others. Professional in the sense of spending a long time building up an identity that seemed trustworthy enough to be made maintainer of an important package, of probably involving multiple people in social manipulation attacks, of not leaking the true identity and source of the attack, and the sophistication and ob…

At this point we don't know who did this. It could have been a single really smart person, it could have been criminal, it could have been a state intelligence agency.

We don't know shit.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#180

Post by bilekas »

asveikau wrote: post #144
EvanAnderson wrote: post #58

Earlier quoted context omitted.

So ifunc is a link-time thing and not a runtime thing, then? (My background, when it comes to linking, is DOS and Windows.)

It's runtime, but I think dynamic linker. The Windows equivalent would be if a library patched some code at dllmain. Actually the Detours library in the Windows world is similar. But it's for performance; the idea is you would patch some function references based on the CPU revision to get faster code specific to your CPU.

This is a really nice windows analogy, however it goes without saying this package wasn't aiming for Windows, ironically, it chose the path (as we seen so far) of least resistance. If you're hooked to an sshd service, your golden. They put 5 checks (maybe comically) in a row to make sure it was linux I this case .. who knows what's next.
Post reply on HN