Apport lock file root privilege escalation
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Apport |
Fix Released
|
Critical
|
Unassigned | ||
apport (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Vulnerable source code (from data/apport):
35 # create lock file directory
36 try:
37 os.mkdir(
38 except FileExistsError as e:
39 pass
40
41 # create a lock file
42 try:
43 fd = os.open(
44 except OSError as e:
45 error_log('cannot create lock file (uid %i): %s' % (os.getuid(), str(e)))
46 sys.exit(1)
When invoked, Apport tries to create the directory /var/lock/apport and continues its execution if the directory already exists.
Since /var/lock is a world writable tmpfs, the probability that /var/lock/apport directory doesn't exist is high, which allows a malicious user to create a symbolic link to the directory of its choice to control the lock file location.
In this case, os.O_NOFOLLOW and fs.protected_
In addition, os.open is called without specifying the "mode" optional argument which by default is set to 0o777. Thus the lock file is created as root and is world writable which opens the door to several root privilege escalation scenarios like, for example, creating the lock file in a cron scripts directory.
All releases containing the bug 1839415 fix (https:/
Fix suggestions:
- If the /var/lock/apport directory already exists and isn't owned by root or owned by root but world writable, remove it and recreate it.
- Specify a mode of 0o600 in the os.open call for the lock file.
Related branches
description: | updated |
information type: | Private Security → Public Security |
Changed in apport: | |
milestone: | none → 2.21.0 |
importance: | Undecided → Critical |
status: | New → Fix Released |
Thanks for reporting this issue, we will investigate it shortly.