3 ms·
>Editor’s note: And this logging functionality was exactly what was abused in last week’s insane liblzma / ssh backdoor. How was the logging functionality of s
by brokenmachine 2y ago
>Editor’s note: And this logging functionality was exactly what was abused in last week’s insane liblzma / ssh backdoor.
How was the logging functionality of systemd abused by the xz backdoor?
- zekrioca 2y agoI guess systemd uses liblzma to automatically compress logs after a configurable timeframe (e.g., daily).
- brokenmachine 2y agoBut wasn't it a backdoor, ie the attacker has to connect via sshd with a specific pubkey to make it run bad commands? As I understand it, just the mere fact liblzma runs on a schedule wouldn't cause it to do anything nefarious.
- 1oooqooq 2y agoso you don't understand it... read on https://www.openwall.com/lists/oss-security/2024/03/29/4 https://www.openwall.com/lists/oss-security/2024/03/29/4 look for the part: "These functions get resolved during startup"
- brokenmachine 2y agoAah, so sshd gets backdoored because systemd calls xz.
- 1oooqooq 2y agono. anything in the dependency tree could call that lib. systemd is the first. systemd also provides libs to write things the exploit will use. but the important part you missed again is that the exploit is executed on symbols loading. it just choose to do just of the work when checking for a key. but after simply starting the code it's all lost already. nothing needs to call any code on libzma, just linking against it is enough to run the exploit.
- brokenmachine 2y agoCalls/links to. meh "important part you missed again" comes off as rude to me. Check yourself.
- 1oooqooq 2y agoit's actually the only interesting part of the exploit code. everything else is just very lame obfuscation
- amiga386 2y agoThat it exists at all. Debian maintainers changed sshd to notify systemd when it is ready. This notification is only a few lines of code, but it's even _fewer_ lines if you call the sd_notify() convenience function in libsystemd.so So now you're linking to libsystemd.so. What's also in libsystemd.so? Logging functionality, for programs that need to read systemd logs. That could be in a separate library, but this is systemd, so of course it's not. Everything's in one library. To read compressed systemd logs, libsystemd.so requires a bunch of compression libraries, including liblzma.so. Anyone linking to libsystemd.so, e.g. to notify at startup, ends up loading liblzma.so, the backdoored version of which abuses glibc ifunc functionality to replace functions in libssl.so in order to take over sshd.
- lyu07282 2y agoLennart actually responded to that point: https://www.mail-archive.com/devel@lists.fedoraproject.org/msg198700.html https://www.mail-archive.com/devel@lists.fedoraproject.org/m... And https://github.com/systemd/systemd/issues/32028#issuecomment-2031366922 https://github.com/systemd/systemd/issues/32028#issuecomment... There are some very compelling arguments made there if you care to read them
- amiga386 2y agoI completely agree, it's at most 50 lines of C code to send a notify message. https://sources.debian.org/patches/openssh/1:9.7p1-4/systemd-readiness.patch/ https://sources.debian.org/patches/openssh/1:9.7p1-4/systemd... If Lennart thinks through that position... sd_notify() shouldn't be in libsystemd.so at all, it's an attractive nuisance. At best it should be in a static library only.
- brokenmachine 2y agoAah ok, thanks for the explanation.
- djbusby 2y agoWould that one-huge-library that depends on so many others be solved with, for example, smaller scoped libs/processes?