6 ms·

People blame systemd for making the liblzma problem larger than it should have been. https://marc.info/?l=openbsd-misc&m=171227941117852&w=2 https://marc.info/

People blame systemd for making the liblzma problem larger than it should have been. https://marc.info/?l=openbsd-misc&m=171227941117852&w=2 https://marc.info/?l=openbsd-misc&m=171227941117852&w=2 "Liblzma ends up dynamically linked to sshd because of a systemd-related extension added by many Linux packagers that pulls in liblzma as an unrelated dependency." https://news.ycombinator.com/item?id=39866076 https://news.ycombinator.com/item?id=39866076 "openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma."

deleted 2y ago
[deleted]
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.
mort96 2y ago
What relevance does this have? Poettering's complaint is that sudo is way too big for a SUID binary, sshd is not a SUID binary? And neither Poettering nor the systemd developers patched said, the Debian people did that. Seems weird to blame systemd for that?
- jpollock 2y ago
  The complaint is that the code architecture of systemd results in security problems for their _customers_. The inclusion of a library to send notifications shouldn't have external dependencies, it shouldn't need them. The library is included in the customer's codebase at execution time, so it is a hole in the customer's security model. This immediately opens a supply chain attack vector (which is what we saw). This is being taken as evidence that they shouldn't have responsibility for truly security sensitive code - the replacement of sudo. Some of this is a long-term dislike for systemd and some representative bias. However, Systemd has missed the opportunity to make their client libraries safer. Personally? I wouldn't have thought to limit the dependencies of my client libraries. It's a growth and project age thing. One moment you're on one side of a line, the next you have to skill up and do things differently. Using systemd as intended shouldn't result in security holes for their customers.
  - mort96 2y ago
    "Systemd is bad because Debian patched OpenSSL to add an unnecessary dependency on a systemd library" is just not a good argument, sorry. Nothing about the "code architecture" of systemd caused the xz issue. And again, Poettering's complaint with sudo is specifically about it being a SUID binary, so this discussion isn't even related to the thing you're accusing them to be hypocritical about... SUID is more than just "code running as root", it's "code running as root in an attacker-controlled environment". That last part is the important one.
    - jpollock 2y ago
      By "code architecture" I mean the packaging of their client libraries. This attack demonstrates that they should be tightly focused and have minimal downstream dependencies. I don't have any experience with systemd, but typically, people will bundle _all_ of their client libraries into one .so and say "use that". However, what needs to happen is there should be multiple .so's, one for each sub-API. At least there should be libraries for frequently used shim code (like notifications seems to be). Then systems that need to push information don't need to pull in the dependencies for other parts of the overall systemd interface. I can't think of a reason why pushing local notifications would require a compression library. The notifications should be information heavy already, so not very compressible. As I said, it's a growth and project age thing. One moment you're on one side of a line, the next you have to skill up and do things differently. How the team responds is what is important. That is why people are objecting to the SUID work. Not because sudo isn't a hole, but that the systemd team isn't considered responsive enough to take it on. I know I'm taking lessons from this to my work. It's an unpleasant mirror for me to look in.

deleted 2y ago

[deleted]

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.

mort96 2y ago

What relevance does this have? Poettering's complaint is that sudo is way too big for a SUID binary, sshd is not a SUID binary? And neither Poettering nor the systemd developers patched said, the Debian people did that. Seems weird to blame systemd for that?

jpollock 2y ago
The complaint is that the code architecture of systemd results in security problems for their _customers_. The inclusion of a library to send notifications shouldn't have external dependencies, it shouldn't need them. The library is included in the customer's codebase at execution time, so it is a hole in the customer's security model. This immediately opens a supply chain attack vector (which is what we saw). This is being taken as evidence that they shouldn't have responsibility for truly security sensitive code - the replacement of sudo. Some of this is a long-term dislike for systemd and some representative bias. However, Systemd has missed the opportunity to make their client libraries safer. Personally? I wouldn't have thought to limit the dependencies of my client libraries. It's a growth and project age thing. One moment you're on one side of a line, the next you have to skill up and do things differently. Using systemd as intended shouldn't result in security holes for their customers.
- mort96 2y ago
  "Systemd is bad because Debian patched OpenSSL to add an unnecessary dependency on a systemd library" is just not a good argument, sorry. Nothing about the "code architecture" of systemd caused the xz issue. And again, Poettering's complaint with sudo is specifically about it being a SUID binary, so this discussion isn't even related to the thing you're accusing them to be hypocritical about... SUID is more than just "code running as root", it's "code running as root in an attacker-controlled environment". That last part is the important one.
  - jpollock 2y ago
    By "code architecture" I mean the packaging of their client libraries. This attack demonstrates that they should be tightly focused and have minimal downstream dependencies. I don't have any experience with systemd, but typically, people will bundle _all_ of their client libraries into one .so and say "use that". However, what needs to happen is there should be multiple .so's, one for each sub-API. At least there should be libraries for frequently used shim code (like notifications seems to be). Then systems that need to push information don't need to pull in the dependencies for other parts of the overall systemd interface. I can't think of a reason why pushing local notifications would require a compression library. The notifications should be information heavy already, so not very compressible. As I said, it's a growth and project age thing. One moment you're on one side of a line, the next you have to skill up and do things differently. How the team responds is what is important. That is why people are objecting to the SUID work. Not because sudo isn't a hole, but that the systemd team isn't considered responsive enough to take it on. I know I'm taking lessons from this to my work. It's an unpleasant mirror for me to look in.