Subscribe to our Threatpost Today newsletter

Join thousands of people who receive the latest breaking cybersecurity news every day.

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

*

*

I agree to my personal data being stored and used to receive the newsletter

*

I agree to accept information and occasional commercial offers from Threatpost partners

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

Hack Crashes Linux Distros with 48 Characters of Code

A Linux admin and open source developer has come up with a 48-character attack that crashes Linux servers, but experts argue the security implications of the bug.

With just a mere 48 characters of code, Linux admin and SSLMate founder Andrew Ayer has figured out how to crash major Linux distributions by locally exploiting a flaw in systemd.

Ayer said the following command, when run as any user, will crash systemd: NOTIFY_SOCKET=/run/systemd/notify systemd-notify “”

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.

“All of this can be caused by a command that’s short enough to fit in a Tweet,” Ayer writes.

Ayer said the flaw was introduced about two years ago in systemd 209. “Despite the banality, the bug is serious, as it allows any local user to trivially perform a denial-of-service attack against a critical system component,” he wrote.

“The above systemd-notify command sends a zero-length message to the world-accessible UNIX domain socket located at /run/systemd/notify. PID 1 receives the message and fails an assertion that the message length is greater than zero” creating the systemd failure, Ayer wrote.

“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” 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.

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.”

Strauss wrote:

“Many of the services systemd helps to harden don’t just have local attack vectors that might become remote ones. Many of them are network services, and they’re not just a foot in the door for other attacks but the keepers of data attackers want.”

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.”

Developer and author of the Linux library musl, Rich Felker, told Threatpost that the systemd bug found by Ayer was less a serious vulnerability and more an alarm bell for a “monoculture” surrounding systemd.

“Systemd is not designed to be broken down into small parts that can safely fail and recover from both a security point of view and a robustness standpoint,” Felker said. “You’ve got one big monolithic process where if one thing breaks the whole thing goes down. That’s the big design problem Ayer is shedding light on. It’s not a big security flaw, it’s a system development design flaw.”

Felker said development of systemd, to the exclusion of alternatives Upstart, Runit and s6, jeopardize a richer more diverse ecosystem of daemons from being developed that would make it harder for hackers to penetrate.

Since Ayer’s original post, the Strauss-Ayer debate has heated up via blogs and Twitter attacks with little sign of relenting.

Discussion

“Systemd is not designed to be broken down into small parts that can safely fail and recover from both a security point of view and a robustness standpoint,” Felker said. “You’ve got one big monolithic process where if one thing breaks the whole thing goes down. That’s the big design problem Ayer is shedding light on. It’s not a big security flaw, it’s a system development design flaw.”

One could make the exact same case against the Linux kernel.
I think what really motivates so many people against systemd is that they simply just love the arcane eliteness of it all...
Most tyros -- and I'll bet most busy admins -- don't.

Yeah, I'd have to agree with that --to a point. I've been using Linux since 1996 (20 years now), and during that time, a lot has changed and a lot hasn't.
On one hand, kernels nowadays tend to take a more modular approach, using external kmods rather than a monolithic design that incorporates everything into a single kernel image.
On the other hand, systemd is really no better than upstart or any other service management system over the past decade, because none of them have made things were the complexity is reduced for building in services from scratch... not to say that they don't do it well.
If anything, that's both the beauty and the horror of these apps. They allow for a great level of complexity, and through that complexity, it allows greater room for discrepancy.
Now... when we look at this through the lens of the professional sysadmin or other Linux professional, we see things in a different light than say through the lens of the average home user or other non-professional Linux user that often has no formal training in services, processing-and-workflow, trouble-shooting, etc.; While the professional might complain a bit about something that they don't care for, they'll still usually train themselves in what they need to know to get their job done; The home user though is more likely to have no idea how to properly secure their systems and services, and so we see a lot of systems with either compromised or broken security because of this.
But yeah... as a semi-retired-sysadmin myself --now working as a cyber-analyst, I personally didn't care that much for systemd at first. But, after the last several weekends, in which I built out a series of systems that used new builds of systemd... I must say that I like the direction that I think that they're going with this. The service definition files (.service files) are much cleaner in structure overall than the old ways of doing things, and that may be really good in the long run because when newer Linux users come to grips with this structure, they'll find that it's well formatted and a lot easier to understand and work with because of that. But I also understand the other way of doing things... part of the reason I got into Linux was because I was bored with Microsoft's platform, because I had done *so much* work on it that I didn't feel at the time that I had any clear direction to continue to increase my technical prowess. Linux gave me a clear avenue to learn so much more about computing, and when I later applied that knowledge across-platform, I found that I had gained a much greater understanding of the foundation of everything-internet that we've come to depend upon, and in turn, that really helped out in my day job --where at that time, I was working as a sysadmin, managing several hundred Windows servers, and a few dozen Linux servers and server appliances. Nowadays, I certainly wouldn't want to manage that group of Linux systems using older methods that take longer to get things done. Nowadays, I'm all about how much time I can save for other, non-technical things, or at least how much time I can save for non-work-related things... R&R, all that. My network at home (consisting of 24 systems on a Gbit backbone throughout the house, incorporating virtualization ) is moving more and more toward Linux each year, and I'd like to have it where it's at least 90% Linux based by the end of next year --it's about 65% Linux based now, with only 5 servers, 1 Z-box, 1 laptop, and 1 tablet running Windows code, with everything else running Linux or BSD. Long term, I plan to migrate my AD infrastructure to Linux based DCs, migrate my PVR system from Windows + NextPVR to Linux + TVHeadend, and my file server from Win2k8 to a specialty distro more designed for turnkey-NAS/SAN type installations. Right now, things are doing fine as they are, but with Windows support being what it is, I'd rather get Windows out of there and replace it with rolling release distros that will grow indefinitely in place... and with that is likely going to be wrestling with whatever emerges eventually to replace systemd, if it doesn't end up being the be-all-end-all of Linux Services Management.
:)

Wow. Real underachiever you are, or what?
:D
I got into GNUnix @ the same time, a little before Debian 'Potato' (started with a Red Hat fork) -- but I had oodles of trouble with the IPC and pre-udev changeovers, et al... and my political work was full-time...
AFAIK, systemd is simply in the 'replace-SysVinit-arcanery-first-as-a-priority' phase -- and that, as the real issues become more clear and apparent over time, the systemd people intend to move on to exactly what concerns you: streamlining and simplifying what will progressively become a more and more elegant, efficient, workable replacement for present-day SysVinit witchcraft.

Authors

Threatpost

InfoSec Insider Post

InfoSec Insider content is written by a trusted community of Threatpost cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Sponsored

Sponsored Post

Sponsored Content is paid for by an advertiser. Sponsored content is written and edited by members of our sponsor community. This content creates an opportunity for a sponsor to provide insight and commentary from their point-of-view directly to the Threatpost audience. The Threatpost editorial team does not participate in the writing or editing of Sponsored Content.