Xz sshd backdoor collecting usernames from logs
isc.sans.eduUnrelated to the quality of the content:
This is not a new vuln. Nothing is actively occurring.
> The author(s) of the backdoor went a long way to make the backdoor look as innocent as possible.
No, not really. The technical part of this backdoor is not interesting at all. Obfuscating strings? Give me a break. That's something your average commercial developer does. It wouldn't even qualify as DRM. Wake me up when the software is self-modifying and/or written in a way that makes IDA crash (seen it a lot, and I am not a security engineer).
"Innocent as possible" would be the something like that Debian weak keys fiasco, or the misleading indentation patch, etc. Those offer much more plausible deniability than this. "Innocent as possible" and interesting technical-wise would be something like the NIST curves. Decades from now people will still be arguing if they are backdoored or not.
The interest in this exploit is on the community/supply side of things, but hardly the technical aspects.
Isn’t it self-modifying in a way? To my understanding code is injected by unpacking the binary test files and injecting right before build?
"Self-modifying" means modifying code at runtime.
From the article: "There is more another function that dynamically modifies code, but that is horrible for reversing – perhaps later ?"
Title is "The amazingly scary xz sshd backdoor" which is... dramatic
Is it? I would describe any backdoor in sshd as amazingly scary.
I wouldn't, as it doesn't seem to add anything to a professional discussion about it. Imagine a doctor describing some advanced cancer as "amazingly scary"
Looks like the site is slowing down: This is the primary source: https://www.openwall.com/lists/oss-security/2024/03/29/4
That's the original report. This article is further inspection of the payload, dating from April 1.