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

The bug is remarkably banal. 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.
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.

The immediate question raised by this bug is what kind of quality
assurance process would allow such a simple bug to exist
for over two years (it was introduced in systemd 209). Isn't the empty
string an obvious test case? One would hope that PID 1, the most
important userspace process, would have better quality assurance than
this. Unfortunately, it seems that crashes of PID 1 are not unusual,
as a quick glance through the systemd commit log reveals commit messages
such as:

Systemd's problems run far deeper than this one bug. Systemd is
defective by design. Writing bug-free software is extremely difficult.
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.

Some degree of complexity is to be expected, as systemd provides a number
of useful and compelling features (although they did not invent them; they
were just the first to aggressively market them). Whether or
not systemd has made the right trade-off between features and complexity
is a matter of debate. What is not debatable is that systemd's complexity does
not belong in PID 1. As Rich Felker explained,
the only job of PID 1 is to execute the real
init system and reap zombies. Furthermore, the real init system, even
when running as a non-PID 1 process, should be structured in a modular
way such that a failure in one of the riskier components does not bring
down the more critical components. For instance, a failure in the
daemon management code should not prevent the system from
being cleanly rebooted.

In particular, any code that accepts messages from untrustworthy sources
like systemd-notify should run in a dedicated process as a unprivileged user. The unprivileged process parses and validates
messages before passing them along to the privileged process. This is
called privilege separation and has been a best practice in security-aware
software for over a decade. Systemd, by contrast, does text
parsing on messages from untrusted sources, in C, running as root in
PID 1.
If you think systemd doesn't need privilege separation because it only
parses messages from local users, keep in mind that in the Internet
era, local attacks tend to acquire remote vectors. Consider
Shellshock,
or the presentation at this year's systemd conference which is titled
"Talking to systemd from a Web Browser."

Setting a umask of 0 means that, by default, any file created by systemd
will be world-readable and -writable. Systemd defines a macro called RUN_WITH_UMASK
which is used to temporarily set a more restrictive umask when systemd needs to create a file
with different permissions. This is backwards. The default umask should be restrictive,
so forgetting to change the umask when creating a file would result in a file
that obviously doesn't work. This is called fail-safe design. Instead systemd is fail-open, so forgetting to change the umask
(which
has already happened twice) creates a file that works but is a potential security vulnerability.

The Linux ecosystem has fallen behind other operating systems in
writing secure and robust software. While Microsoft was hardening
Windows and Apple was developing iOS, open source software became
complacent. However, I see improvement on the horizon. Heartbleed and Shellshock
were wake-up calls that have led to increased scrutiny of open source
software. Go and Rust are compelling, safe languages for writing the type
of systems software that has traditionally been written in C.
Systemd is dangerous not only because it is introducing hundreds of
thousands of lines of complex C code without any
regard to longstanding security practices like privilege
separation or fail-safe design, but because it is setting itself up to be irreplaceable.
Systemd is far more than an init system: it is becoming a secondary
operating system kernel, providing a log server, a device manager,
a container manager, a login manager, a DHCP client, a DNS resolver,
and an NTP client. These services are largely interdependent and
provide non-standard interfaces for other applications to use.
This makes any one component of systemd hard to replace,
which will prevent more secure alternatives from gaining adoption in the
future.

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.