Apport crash report & cron script TOCTTOU

Bug #1862933 reported by Maximilien Bourgeteau on 2020-02-12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apport (Ubuntu)

Bug Description

Vulnerable code (from data/apport):

   700 # we prefer having a file mode of 0 while writing; this doesn't work
   701 # for suid binaries as we completely drop privs and thus can't chmod
   702 # them later on
   703 if pidstat.st_uid != os.getuid():
   704 mode = 0o640
   705 else:
   706 mode = 0
   707 reportfile = os.fdopen(, os.O_RDWR | os.O_CREAT | os.O_EXCL, mode), 'w+b')
   708 assert reportfile.fileno() > sys.stderr.fileno()
   710 # Make sure the crash reporting daemon can read this report
   711 try:
   712 gid = pwd.getpwnam('whoopsie').pw_gid
   713 os.chown(report, pidstat.st_uid, gid)
   714 except (OSError, KeyError):
   715 os.chown(report, pidstat.st_uid, pidstat.st_gid)
   716 except (OSError, IOError) as e:
   717 error_log('Could not create report file: %s' % str(e))
   718 sys.exit(1)

The TOCTTOU takes place between the and the os.chown call and can be fully achieved thanks to the Apport cron script (etc/cron.daily/apport):

     1 #!/bin/sh -e
     2 # clean all crash reports which are older than a week.
     3 [ -d /var/crash ] || exit 0
     4 find /var/crash/. ! -name . -prune -type f \( \( -size 0 -a \! -name '*.upload*' -a \! -name '*.drkonqi*' \) -o -mtime +7 \) -exec rm -f -- '{}' \;
     5 find /var/crash/. ! -name . -prune -type d -regextype posix-extended -regex '.*/[0-9]{12}$' \( -mtime +7 \) -exec rm -Rf -- '{}' \;

The interesting part in this daily script is that the crash reports gets removed if their size is 0.

Since Apport drops real uid and gid, the crashed process owner can send signals during the report file creation. At this time, effective uid and gid are still root.

We can also block Apport by replacing user settings file with a FIFO (~/.config/apport/settings). I'm using the FIFO way in my PoC but it can be done without it.

To make Apport read user settings, the crashing program must not be located in one of those directories (taken from apport/

    78 pkg_whitelist = ['/bin/', '/boot', '/etc/', '/initrd', '/lib', '/sbin/',
    79 '/opt', '/usr/', '/var'] # packages only ship executables in these directories

Once Apport is blocked into FIFO reading, we send the SIGSTOP signal then we write "[main]\nunpackaged=1" into the FIFO so Apport won't exit after resuming (if unpackaged is 0 Apport directly exits because we're not in a "packaged" directory).

After that we "single step" through Apport by sending SIGCONT and SIGSTOP consecutively in a loop until the report file is created with We must make sure os.chown hasn't been called and then we wait for the cron script to remove the report (it's created as root with mode 0 so only root can remove it).

Once removed, we can replace it with a symbolic link/file of the same name, resume Apport with SIGCONT then the file will now be owned by the crashed process user and group.

I think the impact of this vulnerability alone is low because fs.protected_symlinks prevents symlink resolution since we're in a sticky world writable directory (/var/crash), but if it's disabled, you can escalate privileges very easily. It still can be used in some kind of exploit chain though.

My PoC does everything for you except symbolic link/file creation once the report gets removed by the cron script, you have to create it manually then press enter to resume Apport and let the chown happen. You could also create a new crontab entry and directory then copy Apport cron script into it so you don't have to wait the entire day.

Fix suggestions:
- Use reportfile.fileno() instead of the report string for the os.chown calls, and also add follow_symlinks=False argument just in case.
- Remove the size 0 condition in the cron script (not sure about this one, I suppose the condition was there for a reason).

description: updated
description: updated
Marc Deslauriers (mdeslaur) wrote :

Thanks for reporting this issue, we'll investigate promptly.

Seth Arnold (seth-arnold) wrote :

Please use CVE-2020-8833 for this issue: chmod(2) instead of fchmod(2) of the report.

Thanks for the report.

Seth Arnold (seth-arnold) wrote :

Of course that's my mistake, thanks Marc, chown(2) instead of fchown(2).

Alex Murray (alexmurray) wrote :

See attached for a proposed patch against apport in focal to fix both this and LP #1862348 in a single update.

Alex Murray (alexmurray) wrote :

Updated version of patch based on feedback in #1862348

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apport - 2.20.11-0ubuntu22

apport (2.20.11-0ubuntu22) focal; urgency=medium

  * SECURITY UPDATE: World writable root owned lock file created in user
    controllable location (LP: #1862348)
    - data/apport: Change location of lock file to be directly under
      /var/run so that regular users can not directly access it or perform
      symlink attacks.
    - CVE-2020-8831
  * SECURITY UPDATE: Race condition between report creation and ownership
    (LP: #1862933)
    - data/apport: When setting owner of report file use a file-descriptor
      to the report file instead of its path name to ensure that users can
      not cause Apport to change the ownership of other files via a
      symlink attack.
    - CVE-2020-8833

 -- Alex Murray <email address hidden> Wed, 25 Mar 2020 11:28:58 +1030

Changed in apport (Ubuntu):
status: New → Fix Released
Alex Murray (alexmurray) on 2020-04-02
information type: Private Security → Public Security
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Bug attachments