Re: CVE-2021-3997: Uncontrolled recursion in systemd's systemd-tmpfiles

[Solar Designer <solar () openwall com>]

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