[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 18 Feb 2022 17:33:04 +0100
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2021-3997: Uncontrolled recursion in systemd's systemd-tmpfiles
Hi,
Sorry for commenting so late, but:
On Mon, Jan 10, 2022 at 06:08:29PM +0000, Qualys Security Advisory wrote:
> - but if systemd-tmpfiles crashes during the "remove" phase, then it
> never enters the "create" phase;
>
> - and it fails to create the files and directories (specified in
> /usr/lib/tmpfiles.d/*.conf) that it should create at boot time;
>
> - for example, on Ubuntu 21.04, systemd-tmpfiles fails to create the
> directory /run/lock/subsys; but because /run/lock is world-writable,
> attackers can create their own /run/lock/subsys; and because various
> legacy packages and daemons write into /run/lock/subsys as root, the
> attackers may create arbitrary files via symlinks in /run/lock/subsys.
I think the combination of world-writable /run/lock and writes into
/run/lock/subsys as root is a vulnerability on its own, independent of
any systemd issues. This is a matter of failure modes: it's fail-open,
but should be fail-secure.
Further, even without writes into /run/lock/subsys, keeping /run/lock
world-writable unnecessarily allows for DoS attacks against other not
yet started services that would use it.
On the Red Hat'ish systems I've just checked /run/lock is mode 755, on
Debian and Ubuntu it's mode 1777. The only non-root-owned entry under
/run/lock on an Ubuntu system is /run/lock/whoopsie, but that alone does
not tell us whether it was possibly created as root (and then chown'ed).
Either way, keeping /run/lock as world-writable should be avoided, even
if by also changing something in another package.
systemd's tmpfiles.d/legacy.conf.in lists /run/lock as mode 755, and
/run/lock/subsys as mode 755 too. (Incidentally, on Owl we had
/var/lock as mode 755, but /var/lock/subsys as mode 700 with no issues.)
So the Debian and Ubuntu /run/lock mode 1777 looks like those distros'
shortcoming that they should fix.
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
