*** This bug is a duplicate of bug 1839415 ***
https://bugs.launchpad.net/bugs/1839415
** This bug has been marked a duplicate of bug 1839415
Fully user controllable lock file due to lock file being located in
world-writable directory
** Information type changed from Private Security to Public Security
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1839418
Title:
Partially user controllable lock file due to incorrect, too broad
permissions
Status in Apport:
New
Status in apport package in Ubuntu:
New
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1839418/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
