How to crash Linux Systemd with a single command line that fits in a tweet
Linux is supposed to the most secure operating system in the world with very few flaws but a security researcher has discovered that a single command line is enough to crash the popular Systemd feature in Linux.
System administrator Andrew Ayer has discovered a potentially critical bug in systemd which can bring a vulnerable Linux server to its knees with a single command line.”After running this command, PID 1 is hung in the pause system call. You can no longer start and stop daemons. Systemd is an essential part of the boot process for most Linux distributions. According to Ayer, in a blog post titled “How to Crash Systemd in One Tweet,” after running the command, the Linux processes identifier 1 (PID 1) is hung in the pause system call. This prevents a clean system reboot and results in system instability.
“After running this command, PID 1 is hung in the pause system call. You can no longer start and stop daemons. inetd-style services no longer accept connections. You cannot cleanly reboot the system.” says Ayer.
According to the bug report, Debian, Ubuntu, and CentOS are among the distros susceptible to various levels of resource exhaustion. The bug, which has existed for more than two years, does not require root access to exploit.
Ayer says that if a potential hacker runs this command, PID 1 is hung in the pause system call. As a result, you can no longer start and stop daemons while the Linux inetd-style services no longer accept connections. The vulnerability is so critical that you cannot cleanly reboot the system. The system feels generally unstable (e.g. ssh and su hang for 30 seconds since systemd is now integrated with the login system). All of this can be caused by a command that’s short enough to fit in a Tweet.
How to crash systemd in one Tweet:
NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""https://t.co/9HNVhEoeYs
— Andrew Ayer (@__agwa) September 28, 2016
Ayer says that the problem is how systemd handles the command. He says that Systemd’s problems run far deeper than this one bug. ysstemd is defective by design and even good programmers would inevitably introduce bugs into a project of the scale and complexity of systemd. However, good programmers recognize the difficulty of writing bug-free software and understand the importance of designing software in a way that minimizes the likelihood of bugs or at least reduces their impact. The systemd developers understand none of this, opting to cram an enormous amount of unnecessary complexity into PID 1, which runs as root and is written in a memory-unsafe language.
Ayer says that it is not too late to stop this. Although almost every Linux distribution now uses systemd for their init system, init was a soft target for systemd because the systems they replaced were so bad. That’s not true for the other services which systemd is trying to replace such as network management, DNS, and NTP. Systemd offers very few compelling features over existing implementations, but does carry a large amount of risk. If you’re a system administrator, resist the replacement of existing services and hold out for replacements that are more secure. If you’re an application developer, do not use systemd’s non-standard interfaces. There will be better alternatives in the future that are more secure than what we have now. But adopting them will only be possible if systemd has not destroyed the modularity and standards-compliance that make innovation possible.
You can read the bug report on GitHub here.
Since Ayer red-flagged the vulnerability, systemd has patched the denial-of-service bug, according to a David Timothy Strauss, CTO and co-founder of Pantheon. Strauss, via a blog post critical of Ayer, said the vulnerability is a “minor security issue.” “Not only is the current security issue among the lowest risk classes by being local-only and denial-of-service (versus information disclosure or privilege escalation), but most of Ayer’s claims are either wrong or misleading,” Strauss wrote. Strauss takes aim at Ayer’s assertion that the attack code “crashes”
“Not only is the current security issue among the lowest risk classes by being local-only and denial-of-service (versus information disclosure or privilege escalation), but most of Ayer’s claims are either wrong or misleading,” Strauss wrote.
Strauss pooh poohed Ayer’s claim the attack code “crashes” systemd, when in fact it makes it “feel generally unstable.” Strauss says that Ayer is being subjective. “There are some services that attempt to use systemd but will time out in 30 seconds (by default) if it is unavailable. These facilities are degrading gracefully, which is exactly what should happen,” he wrote.
Strauss compares the flaw identified by Ayer as a needed Linux function. “Engineering crumple zones on cars isn’t evidence that they handle poorly. Likewise, improving coredump handling for systemd isn’t evidence that it crashes frequently,” he wrote. In further defense of systemd, Strauss wrote that Ayer is being overly critical of “one of the most powerful tools we have to harden the front lines against the real attacks.”
Ayer has rebutted Strauss’ claims. In Ayer’s latest blog post salvo in response Strauss, he fires back that Strauss “vastly overstates the value of these (systemd) features. “The best systemd can offer is whole application sandboxing. You can start a daemon as a non-root user, in a restricted filesystem namespace, with mandatory access control,” Ayer wrote. “Since sandboxing a whole application cannot protect one part of the application from a compromise of a different part, it is ineffective at securing benign-but-insecure software, which is the problem faced on servers.”
