Vulnerable source code (from data/apport):
35 # create lock file directory
36 try:
37 os.mkdir("/var/lock/apport", mode=0o744)
38 except FileExistsError as e:
39 pass
40
41 # create a lock file
42 try:
43 fd = os.open("/var/lock/apport/lock", os.O_WRONLY | os.O_CREAT | os.O_NOFOLLOW)
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_symlinks (sysctl) have no effect during os.open execution because the symbolic link isn't located in the last component of the given path.
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://bugs.launchpad.net/apport/+bug/1839415) are affected.
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.
Thanks for reporting this issue, we will investigate it shortly.