Partially user controllable lock file due to incorrect, too broad permissions

[Alex Murray]

Author: Sander Bos, <https://www.sbosnet.nl/>

Date: 2019-07-30

Apport creates its lock file, /var/crash/.lock, without providing a
file permission mode. Thus, the file gets created with file permission
mode 777. Users can exploit this, leading to system storage resource
DoS issues (either for mount point "/", or for a potentialy separate
"/var" mount point) as well as Apport service DoS.

Users can thus fill up disks / partitions (although probably not including
the root reserved blocks: even though the file is root owned, the process
writing to the file would be started by the user, not by root, thus
the reserved blocks can probably not be used up). Also, the user may
"hide" data in the file, as well as circumvent a potentially existing
disk quota set on their account. Also, a user putting a lock on the
file leads to DoS on Apport, both individual Apport instances as well
as Apport as a service, as new Apport instances are not able to acquire
the lock and can thus not run. In addition, the file being executable
could have separate security implication on itself.

Note: this issue does not appear on all Ubuntu releases, and / or not when
Ubuntu is installed in an LXC container. This might be due to differences
in the kernel version, differences in the Python version or perhaps
because Ubuntu 14.04 ESM, on which the file gets mode 660 for example,
does not have systemd. More specifically, the issue is probably due to
Apport being called by the kernel via sysctl(8)'s "kernel.core_pattern"
and the kernel not having applied an umask, combined with Python not
creating regular files with "a-x" (as shells do). Also, in the LXC case,
Apport in an LXC container gets called by Apport on the host OS, which
is a "plain" root owned process to which the umask then _does_ apply.

In any case Apport should simply set the correct permissions itself
(probably permission mode 600), which is also the proposed fix for
this issue.