7 ms·

This is another proof that systemd is an anti-pattern for security: with its crawling and ever growing web of dependencies, it extends the surface of vulnerabil

This is another proof that systemd is an anti-pattern for security: with its crawling and ever growing web of dependencies, it extends the surface of vulnerability to orders of magnitude, and once embraced not even large distro communities can defend you from that. A malware code injection in upstream xz-tools is a vector for remote exploitation of the ssh daemon due to a dependency on systemd for notifications and due to systemd's call to dlopen() liblzma library (CVE-2024-3094). The resulting build interferes with authentication in sshd via systemd.

saagarjha 2y ago
This isn't Twitter you don't have to use hashtags
- heptazoid 2y ago
  This isn't Xitter, you don't have to tell people how to write.
acdha 2y ago
Please take the systemd trolling to Reddit. They likely targeted xz specifically because it’s so widely used but there are dozens of other libraries which are potential candidates for an attack on sshd, much less everything else which has a direct dependency unrelated to systemd (e.g. dpkg). Rather than distracting, think about how the open source projects you use would handle an attack like this where someone volunteers to help a beleaguered maintainer and spends time helpfully taking on more responsibilities before trying to weaken something.
- jaromilrojo 2y ago
  You are distracting from facts with speculations and trolling FUD. I refer to what is known and has happened, you are speculating on what is not known.
  - acdha 2y ago
    Your claim is an appeal to emotion trying to build support for a position the Linux community has largely rejected. Starting with the goal rather than looking unemotionally at the facts means that you’re confusing your goal with the attackers’ – they don’t care about a quixotic attempt to remove systemd, they care about compromising systems. Given control of a package which is on most Linux systems and a direct dependency of many things which are not systemd - run apt-cache rdepends liblzma5! – they can choose whatever they want to accomplish that goal. That could be things like a malformed archive which many things directly open or using something similar to this same hooking strategy to compromise a different system component. For example, that includes things like kmod and dpkg so they could target sshd through either of those or, if their attack vector wasn’t critically dependent on SSH, any other process running on the target. Attacking systemd for this is like saying Toyotas get stolen a lot without recognizing that you’re just describing a popularity contest.
- account42 2y ago
  Those other libraries dependend on by sshd are hopefully more closely monitored. The upstream sshd developers probably did not even consider that liblzma could end up being loaded in the process. Make excuses for systemd all you want but loading multiple additional libraries into crytical system deamons just to write a few bytes into a socket is inexcusable and directly enabled this attack vector.
throwaway7356 2y ago
> systemd's call to dlopen() liblzma library (CVE-2024-3094) That's technically wrong, but no surprise. Anti-systemd trolls usually don't understand technical details after all.
- jaromilrojo 2y ago
  It is 10 and more years that I experience such ad-hominem attacks. You are so quickly labeling an identifiable professional as troll, while hiding behind your throwaway identity, that I am confident readers will be able to discern. Meanwhile let us be precise and add more facts https://github.com/systemd/systemd/pull/31550 https://github.com/systemd/systemd/pull/31550 Our community is swamped by people like you, so I will refrain from answering further provocations, believing I have provided enough details to back my assertion.
  - throwaway7356 2y ago
    That MR is not part of any released version of systemd. That is simply to verify: there has been no new systemd release. So much for the "facts". As for trolling: just look at the usual contributions from your community like https://twitter.com/DevuanOrg/status/1619013961629995008 https://twitter.com/DevuanOrg/status/1619013961629995008 Excellent work with the ad-hominem attacks there.
    - lamp987 2y ago
      It's already accepted and merged into master so it will be released in a future systemd release. What's your point? LP in da house?
      - throwaway7356 2y ago
        The MR linked to would actually prevent the backdoor from working, but that doesn't stop some people from claiming it enables the backdoor. But as already said: no surprise given where the comment comes from.
geggo98 2y ago
Actually you have a point. A collection of shell scripts (like the classical init systems) have obviously a smaller attack surface. In this case the attacker used some integration code with systemd to attack the ssh daemon. So sshd without systemd integration is safe against this specific attack. In general, I’m not convinced that systemd makes things less secure. I have the suspicion that the attacker would just have used a different vector, if there was no systemd integration. After all it looks like the attacker was also trying to integrate exploits in owner libraries, like zstd. Still I would appreciate it, if systemd developers would find a better protection against supply chain attacks.
- jaromilrojo 2y ago
  I really appreciate your tone and dialectic reasoning, thanks for your reply. And yes, as simple as it sounds, I believe that shell scripts help a lot to maintain mission critical tools. One hands-on example is https://dyne.org/software/tomb https://dyne.org/software/tomb where I took this approach to replace whole disk encryption which is nowadays also dependent on systemd-cryptsetup.
  - temp12237792 2y ago
    Is this an example of a simple and clean solution via shell script? I have some stylistic doubts: 1. What "exitcode" is set for: exitcode=1 exit 1 2. I see a lot of "return $?". Why "$?" is returned if by default the shell returns the return value of the last command? Just ti name a few: lklfuse -o type=ext4 "${loop}" "$mnt" return $? ... veracrypt --text --non-interactive -d "$file" return $? ... mount "$loop" "$mnt" return $? 3. Aren't =, != etc. used to compare strings and -eq, -ne, -gt etc. used to compare numbers? I see lot of numbers compared as strings, e.g.: [ $? = 0 ] [ $? != 0 ] [ $exitcode = 0 ] 4. There are lot of "cat <<EOF" blocks without indentation. I understand that this is made because the shell expects "EOF" on the line start, but there is a special syntax designed on purpose for this use case, simply put a dash between << and the token, e.g. "cat <<-EOF". In this case: tomb_init() { system="`uname -s`" case "$system" in FreeBSD) cat <<-EOF create=posix_create format=posix_format map=posix_map mount=freebsd_mount close=freebsd_close EOF ;; Linux) 5. Aren't backtick deprecated in favor of $()?

saagarjha 2y ago

This isn't Twitter you don't have to use hashtags

heptazoid 2y ago
This isn't Xitter, you don't have to tell people how to write.

acdha 2y ago

Please take the systemd trolling to Reddit. They likely targeted xz specifically because it’s so widely used but there are dozens of other libraries which are potential candidates for an attack on sshd, much less everything else which has a direct dependency unrelated to systemd (e.g. dpkg). Rather than distracting, think about how the open source projects you use would handle an attack like this where someone volunteers to help a beleaguered maintainer and spends time helpfully taking on more responsibilities before trying to weaken something.

jaromilrojo 2y ago
You are distracting from facts with speculations and trolling FUD. I refer to what is known and has happened, you are speculating on what is not known.
- acdha 2y ago
  Your claim is an appeal to emotion trying to build support for a position the Linux community has largely rejected. Starting with the goal rather than looking unemotionally at the facts means that you’re confusing your goal with the attackers’ – they don’t care about a quixotic attempt to remove systemd, they care about compromising systems. Given control of a package which is on most Linux systems and a direct dependency of many things which are not systemd - run apt-cache rdepends liblzma5! – they can choose whatever they want to accomplish that goal. That could be things like a malformed archive which many things directly open or using something similar to this same hooking strategy to compromise a different system component. For example, that includes things like kmod and dpkg so they could target sshd through either of those or, if their attack vector wasn’t critically dependent on SSH, any other process running on the target. Attacking systemd for this is like saying Toyotas get stolen a lot without recognizing that you’re just describing a popularity contest.
account42 2y ago
Those other libraries dependend on by sshd are hopefully more closely monitored. The upstream sshd developers probably did not even consider that liblzma could end up being loaded in the process. Make excuses for systemd all you want but loading multiple additional libraries into crytical system deamons just to write a few bytes into a socket is inexcusable and directly enabled this attack vector.

throwaway7356 2y ago

> systemd's call to dlopen() liblzma library (CVE-2024-3094) That's technically wrong, but no surprise. Anti-systemd trolls usually don't understand technical details after all.

jaromilrojo 2y ago
It is 10 and more years that I experience such ad-hominem attacks. You are so quickly labeling an identifiable professional as troll, while hiding behind your throwaway identity, that I am confident readers will be able to discern. Meanwhile let us be precise and add more facts https://github.com/systemd/systemd/pull/31550 https://github.com/systemd/systemd/pull/31550 Our community is swamped by people like you, so I will refrain from answering further provocations, believing I have provided enough details to back my assertion.
- throwaway7356 2y ago
  That MR is not part of any released version of systemd. That is simply to verify: there has been no new systemd release. So much for the "facts". As for trolling: just look at the usual contributions from your community like https://twitter.com/DevuanOrg/status/1619013961629995008 https://twitter.com/DevuanOrg/status/1619013961629995008 Excellent work with the ad-hominem attacks there.
  - lamp987 2y ago
    It's already accepted and merged into master so it will be released in a future systemd release. What's your point? LP in da house?
    - throwaway7356 2y ago
      The MR linked to would actually prevent the backdoor from working, but that doesn't stop some people from claiming it enables the backdoor. But as already said: no surprise given where the comment comes from.

geggo98 2y ago

Actually you have a point. A collection of shell scripts (like the classical init systems) have obviously a smaller attack surface. In this case the attacker used some integration code with systemd to attack the ssh daemon. So sshd without systemd integration is safe against this specific attack. In general, I’m not convinced that systemd makes things less secure. I have the suspicion that the attacker would just have used a different vector, if there was no systemd integration. After all it looks like the attacker was also trying to integrate exploits in owner libraries, like zstd. Still I would appreciate it, if systemd developers would find a better protection against supply chain attacks.

jaromilrojo 2y ago
I really appreciate your tone and dialectic reasoning, thanks for your reply. And yes, as simple as it sounds, I believe that shell scripts help a lot to maintain mission critical tools. One hands-on example is https://dyne.org/software/tomb https://dyne.org/software/tomb where I took this approach to replace whole disk encryption which is nowadays also dependent on systemd-cryptsetup.
- temp12237792 2y ago
  Is this an example of a simple and clean solution via shell script? I have some stylistic doubts: 1. What "exitcode" is set for: exitcode=1 exit 1 2. I see a lot of "return $?". Why "$?" is returned if by default the shell returns the return value of the last command? Just ti name a few: lklfuse -o type=ext4 "${loop}" "$mnt" return $? ... veracrypt --text --non-interactive -d "$file" return $? ... mount "$loop" "$mnt" return $? 3. Aren't =, != etc. used to compare strings and -eq, -ne, -gt etc. used to compare numbers? I see lot of numbers compared as strings, e.g.: [ $? = 0 ] [ $? != 0 ] [ $exitcode = 0 ] 4. There are lot of "cat <<EOF" blocks without indentation. I understand that this is made because the shell expects "EOF" on the line start, but there is a special syntax designed on purpose for this use case, simply put a dash between << and the token, e.g. "cat <<-EOF". In this case: tomb_init() { system="`uname -s`" case "$system" in FreeBSD) cat <<-EOF create=posix_create format=posix_format map=posix_map mount=freebsd_mount close=freebsd_close EOF ;; Linux) 5. Aren't backtick deprecated in favor of $()?