4 ms·
From what I’ve read I think the attack vector is: 1. sshd starts and loads the libsystemd library which loads the XZ library which contains the hack 2. The XZ
by skywhopper 3y ago
From what I’ve read I think the attack vector is:
1. sshd starts and loads the libsystemd library which loads the XZ library which contains the hack
2. The XZ library injects its own versions of functions in openssl that verify RSA signatures
3. When someone logs into SSH and presents a signed SSH certificate as authentication, those hacked functions are called
4. The certificate, in turn, can contain arbitrary data that in a normal login process would include assertions about username or role that would be used to determine if the certificate is valid for use logging in as the particular user. But if the hacked functions detect that the certificate was signed by a specific attacker key, they take some subfield of the certificate and execute it as a command on the system in the sshd context (ie, as the root user).
Unfortunately, we don’t know the attacker’s signing key, just the public key the hacked code uses to validate it. But basically this would give the attacker a way to run any command as root on any compromised system without leaving much of a trace, beyond the (presumably failed) login attempt, which any system on the internet will be getting a lot of anyway.
- ghostpepper 3y ago> beyond the (presumably failed) login attempt There is some evidence it's scrubbing logs so we might not even have that.
- Deathcrow 3y agoIs there really a failed login attempts? If it never calls the real functions of ssh in case of their own cert+payload why would sshd log anything or even register a login attempt? Or does the backdoor function hook in after sshd already logged stuff?
- numpad0 3y agoDepending on log level, isn't there going to be lines up to receiving the payload?
- skywhopper 3y agoI think it would depend on logging level, yeah. I’ve not seen one way or another whether it aborts the login process or prevents logging, but that’s possible, and would obviously be a good idea. Then the question would be if you could detect the difference between a vulnerability-aborted login attempt and just a malformed/interrupted login attempt. But in the case of this specific attack, probably the safest approach would be to watch and track what processes are being spawned by sshd. Which in retrospect is probably advisable for any network daemon. (Of course, lots of them will be sloppy and messy with how they interact with the system and it might be next to impossible to tell attacks from “legit” behavior. But sshd is probably easier to pin down to what’s “safe” or not.
- xinayder 3y ago> When someone logs into SSH and presents a signed SSH certificate as authentication, those hacked functions are called So if I only use pubkey auth and ED25519, there's no risk? Besides this, just to understand it better, if someone tries to login to your server with the attacker's certificate, the backdoor will disable any checks for it and allow the remote user to login as root (or any other arbitrary user) even if root login is disabled in sshd config?
- skywhopper 3y agoI don’t think we know enough to be sure even disabling certificate auth would prevent this. But from what I can tell it probably wouldn’t directly allow arbitrary user login. It only seems to allow the execution of an arbitrary command. But of course that command might do something that would break any other security on the system. But, one clever thing about this attack is that the commands being run wouldn’t be caught by typical user-login tracking, since there’s no “login”. The attacker is just tricking sshd into running a command.
- jvans 3y agoSo is the implication here that any system that allows SSH and contains this malicious code is vulnerable?
- MuffinFlavored 3y ago> 2. The XZ library injects its own versions of functions in openssl that verify RSA signatures Specifically how did the xz library patch/hook/inject into the openssl functions that verify RSA signatures?