If I'm reading this right, would there be any persistent evidence of the executed payload? I can't think of a reason anything would have to go to disk in this situation, so a compromise could easily look like an Auth failure in the logs .... maybe a difference in timings .. but that's about it ...
XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
11–20 of 862 posts
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#12EDIT: Here's some more RE work on the matter. Has some symbol remapping information that was extracted from the prefix trie the backdoor used to hide strings. Looks like it tried to hide itself even from RE/analysis, too. https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9... Full list of decoded strings here: https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01 -- For someone unfamiliar with openssl…
> However, since this is an RCE in the context of e.g. an sshd process itself, this means that sshd running as root would allow the payload to itself run as root.
With the right sandboxing techniques, SELinux and mitigations could prevent the attacker from doing anything with root permissions. However, applying a sandbox to an SSH daemon effectively is very difficult.
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#13If I'm reading this right, would there be any persistent evidence of the executed payload? I can't think of a reason anything would have to go to disk in this situation, so a compromise could easily look like an Auth failure in the logs .... maybe a difference in timings .. but that's about it ...
Unless the payload did something that produced evidence, or if the program using openssl that was affected was, for some reason, having all of its actions logged, then no, probably not.
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#14Unpopular opinion, but I cannot but admire the whole operation. Condemn it of course, but still admire it. It was a piece of art! From conception to execution, masterful! We got extremely lucky that it was caught so early.
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#15EDIT: Here's some more RE work on the matter. Has some symbol remapping information that was extracted from the prefix trie the backdoor used to hide strings. Looks like it tried to hide itself even from RE/analysis, too. https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9... Full list of decoded strings here: https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01 -- For someone unfamiliar with openssl…
> However, since this is an RCE in the context of e.g. an sshd process itself, this means that sshd running as root would allow the payload to itself run as root. With the right sandboxing techniques, SELinux and mitigations could prevent the attacker from doing anything with root permissions. However, applying a sandbox to an SSH daemon effectively is very difficult.
Right, though if I'm understanding correctly, this is targeting openssl, not just sshd. So there's a larger set of circumstances where this could have been exploited. I'm not sure if it's yet been confirmed that this is confined only to sshd.
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#16If that's true, then I am 100% certain that this backdoor is from a nation state-level actor.
I already felt like this was way too sophisticated for a random cybercriminal. It's not like making up fake internet identities is very difficult, but someone has pretended to be a good-faith contributor for ages, in a surprisingly long-term operation. You need some funding and a good reason to pull off something like that.
This could also be a ransomware group hoping to break into huge numbers of servers, though. Ransomware groups have been getting more sophisticated and they will already infiltrate their targets for months at a time (to make sure all old backups are useless when they strike), so I wouldn't put it past them to infiltrate the server authentication mechanism directly.
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#17So this basically means to scan for this exploit remotely we'd need the private key of the attacker which we don't have. Only other option is to run detection scripts locally. Yikes.
One completely awful thing some scanners might choose to do is if you're offering RSA auth (which most SSH servers are and indeed the SecSH RFC says this is Mandatory To Implement) then you're "potentially vulnerable" which would encourage people to do password auth instead.
Unless we find that this problem has somehow infested a lot of real world systems that seems to me even worse than the time similar "experts" decided that it was best to demand people rotate their passwords every year or so thereby ensuring the real security is reduced while on paper you claim you improved it.
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#18Is there a git diff which shows this going in?
Apparently it’s not in the original repo, but in a build script in a distribution tar.
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#19Earlier quoted context omitted.
> However, since this is an RCE in the context of e.g. an sshd process itself, this means that sshd running as root would allow the payload to itself run as root. With the right sandboxing techniques, SELinux and mitigations could prevent the attacker from doing anything with root permissions. However, applying a sandbox to an SSH daemon effectively is very difficult.
Right, though if I'm understanding correctly, this is targeting openssl, not just sshd. So there's a larger set of circumstances where this could have been exploited. I'm not sure if it's yet been confirmed that this is confined only to sshd.
The exploit, as currently found, seems to target OpenSSH specifically. It's possible that everything involving xz has been compromised, but I haven't read any reports that there is a path to malware execution outside of OpenSSH.
A quote from the first analysis that I know of (https://www.openwall.com/lists/oss-security/2024/03/29/4):
> Initially starting sshd outside of systemd did not show the slowdown, despite the backdoor briefly getting invoked. This appears to be part of some countermeasures to make analysis harder.
> a) TERM environment variable is not set
> b) argv[0] needs to be /usr/sbin/sshd
> c) LD_DEBUG, LD_PROFILE are not set
> d) LANG needs to be set
> e) Some debugging environments, like rr, appear to be detected. Plain gdb appears to be detected in some situations, but not others
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#20Unpopular opinion, but I cannot but admire the whole operation. Condemn it of course, but still admire it. It was a piece of art! From conception to execution, masterful! We got extremely lucky that it was caught so early.
I agree, but the social engineering parts do feel particularly cruel