"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."
"openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma."
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.
If it was "obviously" broken why was the xz backdoor such a shock to everyone? Do you personally audit the library dependencies of every tool you run, including core servers that come with your distribution? I think people don't do this.
Also, even before the backdoor was discovered, the systemd team were making libxz be dynamically loaded only in the cases where it was needed which would have killed the backdoor dead. There's some evidence that this might have actually caused the backdoor to be sped up and hence led to its discovery. Claims that systemd has bad security have to explain why it was already implementing practices that would have blocked the xz backdoor without it even being discovered. That seems pretty decent to me.
The point is that (even) the systemd maintainers do not vet their dependencies. As an attack vector, it is the (second?) highest level, yet they did not assume the responsibility. Everybody silently assumed they did, hence the shock.
> Claims that systemd has bad security have to explain why it was already implementing practices ...
No, they don't. It doesn't take away the fact that they did not check xz, and probably only few of their other dependencies.
That would be irresponsible and strengthen the case against run0 as a replacement. And let's be honest this time: the argumentation is that it's there to replace sudo.
> It doesn't take away the fact that they did not check xz, and probably only few of their other dependencies.
Xz is also used by Debian's package manager (both dpkg and apt). Or tar. Or the Linux kernel. Or... It already was a system library on Linux systems before systemd started using it as well.
Your post reads like you have no real idea what Xz is and how it is used.
Btw, do you think the Linux kernel developers are also clueless for using Xz?
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.
> 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.
> 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?
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.
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. 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.
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.
Why is this an argument specifically against systemd, rather than all large software projects?
Linux kernel, gcc, glibc - all bundle "a large amount of functionality under a single system" - does this make their design fundamentally flawed as well?
I think a micro-kernel architecture would be better in many ways, security being just one of them. With GCC, it couldn't really be separated into logically distinct modules any more than it already is. All of the constituent parts essentially use the full functionality of the base compiler part, so there is little to be gained separating them. It's not as if the C compiler from GCC, could for instance, be written in such a way that it doesn't depend on GCC. GLibc is a large implementation, but the library itself doesn't necessarily need to be large. There are some very small libcs out there.
On the whole, I do not like monolithic software projects, but I can accept that they are necessary or beneficial in some cases. Systemd is simply a much bigger target than these other things because it is an especially bad example. It has many components which are only tentatively connected. It is also more fixable. Alternate init systems are used much more widely than something like Hurd to replace Linux. The laptop I'm typing this from runs GuixSD which ships without Systemd and I can hardly notice the difference. I doubt a different kernel architecture would provide such a seamless experience.
Given how common LZMA as a compression algorithm is, are you certain that your init system of choice doesn’t use it in any way? It’s a very common algorithm in network protocols, it’s a direct dependency of libxml, … - and if any part of your init system uses LZMA, then it just happens not to be affected because the attacker chose to target one specific system.
The attacker had essentially full control over a very fundamental library in the Linux ecosystem. They could have leveraged that in a hundred ways.
The attacker chose to target a very specific component of a very specific system. It was their choice, not some sort of technical requirement that made it impossible to use a different attack vector. Just as they chose not to target other Linux distributions that use systemd.
You’re essentially saying “I was safe because the attacker chose to ignore me.” That worked well this time, but it’s a pretty dangerous stance.
When a hacker chooses to attack something, that isn't random. They had to look at a lot of different pieces of software, and decide which would be the best to attack. The choice in this case was Systemd. In other words, if you are looking to do malicious things, Systemd is helpful.
Now I want you to imagine that every piece of software has a score, which tells you how useful it is to hackers. Systemd has a high score, and hence it was chosen for this attack. Your argument is that: there are other pieces of software with a high score so it's fine for Systemd to also have one, since without it there would be other things to attack. My argument is that we should reduce the amount of software that has a high score. Do you think my reasoning or your reasoning will lead to a more secure ecosystem?
> - 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.
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. 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.
> 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.
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.
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.
"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.
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.
The complaint might be valid. The solution, to shoehorn yet another functionality on systemd will in no way reduce complexity or attack vectors, merely shift them, again, like with all systemd solutions.
What difference does it make if it's part of the systemd project or not? Do things suddenly become a more problematic attack vector when they're organizationally part of the systemd project instead of the sudo project?
Because that's what he's complaining about