4 ms·
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 expl
by junon 3y ago
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.
- jeroenhd 3y agoThe 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 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