[sf-lug] The sky is [not] falling ... again (Re: Verifiably critical systemd vulnerability anyone?) ... CVE-2021-33910
Michael.Paoli at cal.berkeley.edu
Tue Jul 20 19:20:29 PDT 2021
The more-or-less usual, and not a huge deal.
Sure, not pretty, but ...
Thus far appears it's "only" a DoS vulnerability, and
requires local user to be able to run relatively arbitrary commands - or
at least certain commands and using relatively arbitrarily long strings.
And yes, it can - via our not-so-old frenemy systemd, crash the system
by critically running the host out of memory.
And yes, Qualsys found it and responsibly disclosed it.
But their main article on it:
surprise surprise ... not ... spends about 2/3 of it pushing ...
of course Qualsys product(s) because, hey, they're a security products
vendor. So, "of course" if they can whip folks into a frenzied panic,
and maybe also get 'em to buy more Qualsys security products ... uhm,
do we see a problem here? And unfortunately too many "journalists"/reporters
buy the hype and run with stuff like "that's bad, that's really bad.", e.g.:
Sure, not pretty, kind'a embarrassing for systemd ... if systemd cares
enough to be embarrassed. But it's not *that* bad. If one takes it in
the context of all the damage a maliciously intended local user on a
Linux host can cause ... yeah, crashing the host isn't that big a deal and
probably fairly easy to do on most hosts that aren't fairly well hardened
to thwart such relatively child's play level attacks from a local user
that can run relatively arbitrary unprivileged commands.
So, don't panic. And, most anyone who pays reasonable attention to
security - like being subscribed to and watching the announcements about
security for relevant distro(s) one is running, generally got this
information earlier. E.g. there was ...
2021-07-20: Coordinated Release Date (12:00 PM UTC)
and I'm running Debian, so ... Debian had the list
email out at:
And I received it at:
"There's no way to remedy this problem."
<cough> Uhm, no. You update systemd ... for better and/or worse, on
at least many distros, systemd will even replace the existing running
systemd - so can even be fixed without need to reboot. Can also
remedy the problem by not running systemd. Some distros, e.g. Debian,
offer more than one init system - so one needn't run systemd. Some
distros go even further - e.g. Devuan entirely excludes systemd and
doesn't even offer systemd as a choice.
> From: aaronco36 <aaronco36 at SDF.ORG>
> Subject: [sf-lug] Verifiably critical systemd vulnerability anyone?
> Date: Tue, 20 Jul 2021 22:34:54 +0000 (UTC)
> FYI, am using a non-systemd-init Linux distro at the moment.
> Quoting OpenCVE's earlier 'CVE-2021-33910' webpage at
> https://www.opencve.io/cve/CVE-2021-33910 :
> basic/unit-name.c in systemd 220 through 248 has a Memory Allocation
> with an Excessive Size Value (involving strdupa and alloca for a
> pathname controlled by a local attacker) that results in an
> operating system crash.
> More extensively quoting Steven J. Vaughan-Nichols' more explanatory
> ZDNet article 'Nasty Linux systemd security bug revealed' at
> Qualsys has found an ugly Linux systemd security hole that can
> enable any unprivileged user to crash a Linux system. The patch is
> available, and you should deploy it as soon as possible.
> Systemd, the Linux system and service manager that has largely
> replaced init as the master Linux startup and control program,
> has always had its critics. Now, with Qualys's discovery of a new
> systemd security bug, systemd will have fewer friends. Successful
> exploitation of this newest vulnerability enables any unprivileged
> user to cause a denial of service via a kernel panic.
> In a phrase, "that's bad, that's really bad."
> As Bharat Jogi, Qualys's senior manager of Vulnerabilities and
> Signatures, wrote, "Given the breadth of the attack surface for this
> vulnerability, Qualys recommends users apply patches for this
> vulnerability immediately." You can say that again.
> Systemd is used in almost all modern Linux distributions. This
> particular security hole arrived in the systemd code in April 2015.
> It works by enabling attackers to misuse the alloca() function in a
> way that would result in memory corruption. This, in turn, allows a
> hacker to crash systemd and hence the entire operating system.
> Practically speaking, this can be done by a local attacker mounting
> a filesystem on a very long path. This causes too much memory
> space to be used in the systemd stack, which results in a system
> That's the bad news. The good news is that Red Hat Product
> Security and systemd's developers have immediately patched the
> There's no way to remedy this problem. While it's not present in all
> current Linux distros, you'll find it in most distros such as the
> Debian 10 (Buster) and its relatives like Ubuntu and Mint.
> Therefore, you must, if you value keeping your computers working,
> patch your version of systemd as soon as possible. You'll be glad
> you did.
More information about the sf-lug