> The developer talks about the weaknesses of sudo, and how it has a large possible attack surface
Poettering's hypocrisy is painful.
replies(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
"openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma."
- 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?
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.
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.
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.
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.
And neither Poettering nor the systemd developers patched said, the Debian people did that. Seems weird to blame systemd for that?
> - 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.
The hypocrisy is in calling out a different project for being an overengineered tool running with too high privileges.
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.
It was purely the attackers choice to leverage the exploit via systemd instead of injecting code in the kernel at build time.
Linux kernel, gcc, glibc - all bundle "a large amount of functionality under a single system" - does this make their design fundamentally flawed as well?
> 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.
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.
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.
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.
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.
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?
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?
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.
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.
There's lots of projects that link xz, big and small. Patching sshd to include any of them would have implemented the backdoor.
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?