[sf-lug] The sky is [not] falling ... again (Re: Verifiably critical systemd vulnerability anyone?) ... CVE-2021-33910

[Michael Paoli]

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:
https://blog.qualys.com/vulnerabilities-threat-research/2021/07/20/cve-2021-33910-denial-of-service-stack-exhaustion-in-systemd-pid-1
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.:
https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
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:
2021-07-20T12:53:51+00:00
https://lists.debian.org/debian-security-announce/2021/msg00125.html
And I received it at:
2021-07-20T13:10:00+00:00

"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  
> https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/  
> :
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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[1], the Linux system and service manager that has largely  
> replaced init[2] as the master Linux startup and control program,  
> has always had its critics. Now, with Qualys's[3] discovery of a new  
> systemd security bug[4], 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[5]. This causes too much memory  
> space to be used in the systemd stack, which results in a system  
> crash.
>
> That's the bad news. The good news is that Red Hat Product  
> Security[6] and systemd's developers have immediately patched the  
> hole.
>
> 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)[7] and its relatives like Ubuntu[8] and Mint[9].  
> 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.