Live data from Hacker News

The xz sshd backdoor rabbithole goes quite a bit deeper

twitter.com

221–230 of 310 posts

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

#221

I often wonder with these sort of things, where there are lots of write-ups by geeks who dive-deep into the details, why do people say "This has to be state sponsored!", "Look at the timestamps! Irrefutable proof!" Yes this was sneaky and yes this was a "slow burn" but is there really anything in the xz case that requires more than just a single competent person? Anything that requires state-level of sponsorship? The…

The biggest thing for me that points to a state actor is the amount of time committed to the social engineering attack versus the expected value of the prize. A for-profit scheme built this way would be irrational, which doesn't preclude it being an irrational actor (or an individual with a motive other than profit) but does point to a state actor as a likely candidate.

The total value of the prize, if successful, would be worth a lot if you could sell it, but the odds of successfully getting an exploit into major infrastructure that goes undetected for long enough for your customers to buy and use it are tiny. States can afford moonshots, but I tend to expect private individuals to seek targets with a higher expected value.

Of course, that doesn't mean it was a competent state actor or that they allocated a ton of resources to it.

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

#222

I haven't been following this story super closely but I find it extremely odd that I've heard zero discussion about the perpetrator of this hack.

I would be interested in semantic analysis of the communication from the involved online personas, similar to what was done for Satoshi, to point to a cultural direction. Would also be interesting to see if there were semantic style differences over time pointing to different people acting as the personas. Since it would be quite a lot of code that has been committed as well, would also be interesting to see if code…

There is nothing of value to gain from such analysis. Even if evidence turns up, it would be even more flimsy than graphology.

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

#223
post #137
post #129

Earlier quoted context omitted.

Like I said, we don't know anything worth having a real discussion about. Maybe he was in the +03 time zone, and pretending to be in +08, but that's not enough to base a discussion on.

You're discussing it.

We are all speculating.

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

#224
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…

I find this the most plausible explanation by far:

* The highly professional outfit simply did not see teknoraver's commit to remove liblzma as standard dependency of systemd build scripts coming.

* The race was on between their compromised code and that commit. They had to win it, with as large a window as possible.

* This caused the amateuristic aspects: Haste.

* The performance regression is __not__ big. It's lucky Andres caught it at all. It's also not necessarily all that simple to remove it. It's not simply a bug in a loop or some such. If I was the xz team I'd have enough faith in all the work that was done to give it high odds that they'd get there before discovery. That they'd have time; months, even.

* The payload of the 'hack' contains fairly easy ways for the xz hackers to update the payload. They actually used it to remove a real issue where their hackery causes issues with valgrind that might lead to discovering it, and they also used it to release 5.6.1 which rewrites significant chunks; I've as yet not read, nor know of any analysis, as to why they changed so much. Point is, it's reasonable to think they had months, and therefore, months to find and fix issues that risk discovery.

* I really can't spell this out enough: WE GOT REALLY LUCKY / ANDRES GOT LUCKY. 9 times out of 10 this wouldn't have been found in time.

Extra info for those who don't know:

https://github.com/systemd/systemd/commit/3fc72d54132151c131...

That's a commit that changes how liblzma is a dependency of systemd. Not because the author of this commit knew anything was wrong with it. But, pretty much entirely by accident (although removing deps was part of the point of that commit), almost entirely eliminates the value of all those 2 years of hard work.

And that was with the finish line in sight for the xz hackers: On 24 feb 2024, the xz hackers release liblzma 5.6.0 which is the first fully operational compromised version. __12 days later systemd merges a commit that means it won't work__.

So now the race is on. Can they get 5.6.0 integrated into stable releases of major OSes _before_ teknoraver's commit that removes liblzma's status as direct dep of systemd?

I find it plausible that they knew about teknoraver's commit _just before_ Feb 24th 2024 (when liblzma v5.6.0 was released, the first backdoored release), and rushed to release ASAP, before doing the testing you describe. Buoyed by their efforts to add ways to update the payload which they indeed used - March 8th (after teknoraver's commit was accepted) it was used to fix the valgrind issue.

So, no, I don't find this weird, and I don't think the amateurish aspects should be taken as some sort of indication that parts of the outfit were amateuristic. As long as it's plausible that the amateuristic aspects were simply due to time pressure, it sounds like a really bad idea to make assumptions in this regard.

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

#225

Earlier quoted context omitted.

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

I would say you put too much faith into military-like organization as well. However, from what I can tell it's usually just ordinary security researchers and devs with dubious morals (some are probably even former cybercriminals) that usually don't even have the need-to-know and aren't necessarily aware of every single aspect of their work. The entire thing is likely compartmentalized to hell. You can't conjure quali…

> it's usually just ordinary security researchers and devs with dubious morals (some are probably even former cybercriminals)

not sure if we should easily judge offsec and the private-public partnership that provides intel and offensive capabilities.

whether they're ex-criminals or must be accused of "dubious morals" would depend whether their clients (or targets) are what one considers the enemy.

and what about the guy who silently works on a "dubious project" patiently for years ... and then, at the right moment, knowingly throws a spanner in the works? aren't they the true hero?

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

#226
post #178

Earlier quoted context omitted.

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.

not just at coding. as a class of people, they tend to not be the sharpest tools in the shed.

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

#227

it's a rather good thing that this was found before it made it out broadly. Not just for obvious reason of not wanting an unknown party to have RCE on your infrastructure. I think as people keep digging they will eventually formulate a payload which will allow the backdoor to be used by anyone. As bad as it is for a single party to have access, it's much worse for any (every?) party to have access.

Isn’t that more or less impossible since the payload is a private RSA key?

That sort of assumes that the backdoor in question is free of all bugs (for example, buffer overflows).

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

#228
post #166

Earlier quoted context omitted.

Welp. Ok, well now my newest worst nightmare is a jira board with tickets for "Iran" and "North Korea" stuck in the wrong column and late-night meetings with "product" about features.

The realization that there IS NOT an all powerful super intelligent cabal running everything is the worst one. What we have is an Illuminati that is using Jira. :(

I think this is a key insight with some details: there isn’t an entire shadowy org that operates without jira but there are teams of people, usually small who do amazing things without jira. I imagine the manhattan project ran this way but you still have elite teams like this in every org. Eventually they need to hand it off to a jira crew and that’s unavoidable.

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

#229
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…

So, much like any other code base.

Bit of a https://en.wikipedia.org/wiki/Curate%27s_egg

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

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

> Writing proper error handling in C is a very tedious and error prone task.

Managing C dependencies is even more tedious and error prone. And even in C, opening a UNIX domain socket to write a single packet is not that hard.

Post reply on HN