so like why can’t i find anyone who’s actually analysed how the xz backdoor ssh auth bypass works
*: nobody has bothered publishing an analysis of how the backdoor itself works and what conditions are required for it to be used
You must log in to comment.
in reply to @bark's post:
I saw some discussion earlier today of “oh this is harder than usual to reverse engineer” I’m sure someone will do it there’s just a smaller group of people who can do it and it’s only been like 40 hours.
Also all the people busy doing analysis of how it’s actually getting injected in the first place.
seems like people are working on it (some links at https://boehs.org/node/everything-i-know-about-the-xz-backdoor) but it appears the payload is pretty damn complex
in reply to @bark's post:
Here's Filippo Valsorda's thread about the RCE: https://bsky.app/profile/did:plc:x2nsupeeo52oznrmplwapppl/post/3kowjkx2njy2b
I don't think anyone has a public, full analysis yet, and there are major obstacles in the way of a full repro — Filippo links to a repro script that can reach RSA_public_decrypt, but presumably only the attacker has the Ed448 key required to trigger the full vulnerability. Which is more sophisticated than the authentication bypass that was Friday's best bet. And means any 'live' analysis would have to find a way around that roadblock.
Then once you get past that, from what I understand the (apparently incredibly cursed) assembly assembles shellcode from other parts of the binary (which means the binary layout is important!), and then passes that to system(). That's all I know.
Andres Freund listed some requirements for the backdoor to trigger back in his initial email.
So, we knew that it existed and that it did something bad to SSH from hour 0, but I'm not surprised that an exploit as sophisticated as this one doesn't have a full public analysis at hour 41.
One critical piece here that filippo's thread touches on but doesn't explain in detail: the backdoor expects the be provided with a signed object, and expects that the signature come from the attacker's hardcoded key... but also expects that the signature be computed over a hash of the compromised server's own pubkey. So the attacker presumably has a script which connects to an instance, gets its pubkey, and then computes and signs the malicious payload. This means that we can't produce our own working malicious requests until we figure out how to change the key it's looking for, and we can't replay captured malicious requests against different hosts for analysis.
That degree of overengineering definitely says a thing or two about who made this.