[Bug 1839418] Re: Partially user controllable lock file due to incorrect, too broad permissions

[Alex Murray]

*** 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
Foundations Bugs, 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