5 ms·

So that's your best shot against systemd? - Linux packagers decide to patch sshd to use libsystemd for a notification, that could have been trivially done with

by deng 2y ago

So that's your best shot against systemd? - Linux packagers decide to patch sshd to use libsystemd for a notification, that could have been trivially done without this library. - libsystemd depends on libzlma - libzlma depends on xz And therefore, systemd is insecure? And what does this have to do with the fact that SUID is a terrible idea that needs to go?

lmm 2y ago
> - Linux packagers decide to patch sshd to use libsystemd for a notification, that could have been trivially done without this library. Why was that? Would that "trivial" approach have broken the next time systemd made one of their incompatible interface changes, perhaps? Was using libsystemd the kind of thing the systemd maintainers recommended? > And therefore, systemd is insecure? Systems with systemd had a vulnerability that systems without systemd did not. So it certainly seems like systemd-the-system (not necessarily systemd-the-unix-process) is bad for security.
- Xylakant 2y ago
  You're not making a very good point here. A lot of packages have a transitive dependency on liblzma - for example everything that depends on libxml since that depends on liblzma https://packages.debian.org/sid/libxml2 https://packages.debian.org/sid/libxml2. LZMA is a pretty widely used compression algorithm, I'm absolutely certain there's other juicy targets that depend on liblzma. The reason why "only" sshd on debian/ubuntu was affected is that the attacker chose to tailor their exploit to those systems. Systemd was the vehicle, debian patching opensshd was what made this specific incarnation of the attack possible, but essentially, both trusted a widely used library.
  - lmm 2y ago
    > A lot of packages have a transitive dependency on liblzma - for example everything that depends on libxml since that depends on liblzma https://packages.debian.org/sid/libxml2 https://packages.debian.org/sid/libxml2. Sure. But security-critical software like SSH would certainly think twice before bringing in such a huge and complex dependency as an XML parser. > I'm absolutely certain there's other juicy targets that depend on liblzma. You could probably make a system package manager (which has obvious reasons to depend on a compression algorithm) do something nefarious. But that would be a more complex chain of exploitation with more chance for things to go wrong. Most security teams put more attention on security-critical parts like SSH, and I think most people would agree they're right to do so.
- mort96 2y ago
  My understanding is that the UNIX socket based protocol which libsystemd wraps for this specific feature is documented, stable and simple.
tgv 2y ago
First, getting rid of setuid (I guess you'd have to get rid of the whole thing, not just the permission bit) is not the same as making systemd an integral part of the OS. Second, when even the package maintainers can make such "trivial" mistakes, something is wrong. You'd expect a component such as systemd to be much more trustworthy than some random library. I'm not arguing against systemd, just that it seems to grow and grow, and is not the correct place for security. It security is obviously broken.
- deng 2y ago
  > First, getting rid of setuid (I guess you'd have to get rid of the whole thing, not just the permission bit) is not the same as making systemd an integral part of the OS. It absolutely is. sudo allows you to execute code as another user. If you want to do that without giving sudo itself administrative privileges, this has to be done through the service manager, which creates a completely new, elevated process and handles communication with that. This is how it should be done (and BTW, this is pretty much how also the new sudo for Windows works). Now Lennart for some reason prefers systemd as this service manager - you might disagree with that choice, but then come up with a better one.
  - tgv 2y ago
    Decoupling/single-reponsibility is sort of lesson #1 in software engineering. > then come up with a better one. Really?
    - deng 2y ago
      > Decoupling/single-reponsibility is sort of lesson #1 in software engineering. Well said. What makes you think systemd does not do this? Have you ever even looked at systemd in any amount of detail? Do you think it is one big binary running as PID1 doing everything?
- jononor 2y ago
  Package maintainers of a distro can do absolutely anything to a package. With zero input from upstream developers. Some distros have more tradition for patching software than others. An upstream like systemd (or openssh) can hardly be blamed for what others do with their software.
James_K 2y ago
> - libsystemd depends on libzlma > - libzlma depends on xz > And therefore, systemd is insecure? Yes. You have literally just described the way it is insecure. It bundles a large amount of functionality under a single system, and therefore anything using that functionality is at risk. You seem to be suggesting that Systemd would be secure if you didn't use it, which is obviously fallacious. Anything is secure if you don't use it. Systemd offers this functionality, and did it in an insecure way. You cannot blame users for that. Saying that people shouldn't be using a certain part of Systemd is really the same as saying that part shouldn't exist to begin with. The conclusion is obviously that Systemd should be smaller to decrease the chances of things like this happening.
- Xylakant 2y ago
  LZMA is a widely used compression protocol. The kernel uses it. xz - the compression tool that was affected gets used by the kernel build makefiles - they reference it in the build docs https://docs.kernel.org/staging/xz.html https://docs.kernel.org/staging/xz.html. It's absolutely fair from systemd to have this dependency and to use the trusted library that the most fundamental part of the underlying OS uses. It was purely the attackers choice to leverage the exploit via systemd instead of injecting code in the kernel at build time.
  - James_K 2y ago
    Your speculation on what is right and what was fair is of no consequence to me. Their error was not simply using a compression library, it was creating a large central point of failure. If Systemd was smaller, it would not have caused this error. By being large, it made itself vulnerable. It made itself a target. It made other software insecure. These facts are inescapable. And you cannot justify this by simply saying they didn't do anything wrong right before the attack, or that packagers are to blame, or that other software might also be vulnerable, or anything else that doesn't address the core of the issue: Systemd created the circumstances needed for this to happen. They were warned of he risks they created, and chose to do so anyway. Now those risks have been made manifest – the inevitable result of a fundamentally flawed design.

by deng 2y ago

lmm 2y ago

> - Linux packagers decide to patch sshd to use libsystemd for a notification, that could have been trivially done without this library. Why was that? Would that "trivial" approach have broken the next time systemd made one of their incompatible interface changes, perhaps? Was using libsystemd the kind of thing the systemd maintainers recommended? > And therefore, systemd is insecure? Systems with systemd had a vulnerability that systems without systemd did not. So it certainly seems like systemd-the-system (not necessarily systemd-the-unix-process) is bad for security.

Xylakant 2y ago
You're not making a very good point here. A lot of packages have a transitive dependency on liblzma - for example everything that depends on libxml since that depends on liblzma https://packages.debian.org/sid/libxml2 https://packages.debian.org/sid/libxml2. LZMA is a pretty widely used compression algorithm, I'm absolutely certain there's other juicy targets that depend on liblzma. The reason why "only" sshd on debian/ubuntu was affected is that the attacker chose to tailor their exploit to those systems. Systemd was the vehicle, debian patching opensshd was what made this specific incarnation of the attack possible, but essentially, both trusted a widely used library.
- lmm 2y ago
  > A lot of packages have a transitive dependency on liblzma - for example everything that depends on libxml since that depends on liblzma https://packages.debian.org/sid/libxml2 https://packages.debian.org/sid/libxml2. Sure. But security-critical software like SSH would certainly think twice before bringing in such a huge and complex dependency as an XML parser. > I'm absolutely certain there's other juicy targets that depend on liblzma. You could probably make a system package manager (which has obvious reasons to depend on a compression algorithm) do something nefarious. But that would be a more complex chain of exploitation with more chance for things to go wrong. Most security teams put more attention on security-critical parts like SSH, and I think most people would agree they're right to do so.
mort96 2y ago
My understanding is that the UNIX socket based protocol which libsystemd wraps for this specific feature is documented, stable and simple.

tgv 2y ago

First, getting rid of setuid (I guess you'd have to get rid of the whole thing, not just the permission bit) is not the same as making systemd an integral part of the OS. Second, when even the package maintainers can make such "trivial" mistakes, something is wrong. You'd expect a component such as systemd to be much more trustworthy than some random library. I'm not arguing against systemd, just that it seems to grow and grow, and is not the correct place for security. It security is obviously broken.

deng 2y ago
> First, getting rid of setuid (I guess you'd have to get rid of the whole thing, not just the permission bit) is not the same as making systemd an integral part of the OS. It absolutely is. sudo allows you to execute code as another user. If you want to do that without giving sudo itself administrative privileges, this has to be done through the service manager, which creates a completely new, elevated process and handles communication with that. This is how it should be done (and BTW, this is pretty much how also the new sudo for Windows works). Now Lennart for some reason prefers systemd as this service manager - you might disagree with that choice, but then come up with a better one.
- tgv 2y ago
  Decoupling/single-reponsibility is sort of lesson #1 in software engineering. > then come up with a better one. Really?
  - deng 2y ago
    > Decoupling/single-reponsibility is sort of lesson #1 in software engineering. Well said. What makes you think systemd does not do this? Have you ever even looked at systemd in any amount of detail? Do you think it is one big binary running as PID1 doing everything?
jononor 2y ago
Package maintainers of a distro can do absolutely anything to a package. With zero input from upstream developers. Some distros have more tradition for patching software than others. An upstream like systemd (or openssh) can hardly be blamed for what others do with their software.

James_K 2y ago

> - libsystemd depends on libzlma > - libzlma depends on xz > And therefore, systemd is insecure? Yes. You have literally just described the way it is insecure. It bundles a large amount of functionality under a single system, and therefore anything using that functionality is at risk. You seem to be suggesting that Systemd would be secure if you didn't use it, which is obviously fallacious. Anything is secure if you don't use it. Systemd offers this functionality, and did it in an insecure way. You cannot blame users for that. Saying that people shouldn't be using a certain part of Systemd is really the same as saying that part shouldn't exist to begin with. The conclusion is obviously that Systemd should be smaller to decrease the chances of things like this happening.

Xylakant 2y ago
LZMA is a widely used compression protocol. The kernel uses it. xz - the compression tool that was affected gets used by the kernel build makefiles - they reference it in the build docs https://docs.kernel.org/staging/xz.html https://docs.kernel.org/staging/xz.html. It's absolutely fair from systemd to have this dependency and to use the trusted library that the most fundamental part of the underlying OS uses. It was purely the attackers choice to leverage the exploit via systemd instead of injecting code in the kernel at build time.
- James_K 2y ago
  Your speculation on what is right and what was fair is of no consequence to me. Their error was not simply using a compression library, it was creating a large central point of failure. If Systemd was smaller, it would not have caused this error. By being large, it made itself vulnerable. It made itself a target. It made other software insecure. These facts are inescapable. And you cannot justify this by simply saying they didn't do anything wrong right before the attack, or that packagers are to blame, or that other software might also be vulnerable, or anything else that doesn't address the core of the issue: Systemd created the circumstances needed for this to happen. They were warned of he risks they created, and chose to do so anyway. Now those risks have been made manifest – the inevitable result of a fundamentally flawed design.