** Tags added: id-5d640fd329dff226b88f059a -- 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/1839415
Title: Fully user controllable lock file due to lock file being located in world-writable directory Status in Apport: New Status in apport package in Ubuntu: Fix Released Bug description: Author: Sander Bos, <https://www.sbosnet.nl/> Date: 2019-07-30 In data/apport, Apport creates a lock file: 35 # create a lock file 36 lockfile = os.path.join(apport.fileutils.report_dir, '.lock') 37 try: 38 fd = os.open(lockfile, os.O_WRONLY | os.O_CREAT | os.O_NOFOLLOW) The value of "apport.fileutils.report_dir" is /var/crash/, which is a world-writable (but sticky) directory. Placing the lock file in a world-writable directory as done here effectively makes the lock file fully controllable by any user, at least as long as the lock file does not already exist, i.e., in case Apport has not been executed before (but a different issue exists which completely defeats this precondition). This issue can be exploited in several ways, with various impacts. Probably being its most severe impact, a simple shell one-liner like the following will lead to a complete system DoS, i.e., DoS on the OS resource level (e.g., memory): $ mkfifo /var/crash/.lock && while sleep 100 & do sleep 1; kill -11 "$!"; kill -9 "$!"; done This will make the os.open() in data/apport stall forever due to the FIFO file, as well as create more than one and up to an indefinite amount of (root owned) Apport processes due to the failing of the locking mechanism, which should normally prevent subsequent Apport processes from running, because the lock is not yet set at that point. The "kill -9" prevents the user from hitting its "RLIMIT_NPROC" limit, and "RLIMIT_CORE" itself does not apply to the root user. The locking mechanism failing when using a FIFO file, i.e., circumventing the locking mechanism thus making it possible to run more than one Apport process at the same time (even when they are in a stalled state) is an impact on its own, not just in the OS DoS scenario in which it is abused up to the point creating many Apport instances ultimately leading to OS DoS. Also, the issue in the first place leads to DoS for Apport both for individual instances as well as it as a service as a whole, i.e., making Apport unable to function, as one user could create a /var/crash/.lock FIFO file and prevent Apport from doing its work in case of program crashes of other users. This issue when used with a FIFO file can also be abused to "time" Apport, i.e., let Apport stall for some period of time (and do whatever is needed to control the further flow of Apport during that time, e.g., as part of a larger exploit scenario) and have it continue at a specific, user defined moment by then reading out the FIFO file. As a different method of exploitation of this issue, a user can simply create /var/crash/.lock (as a regular file) and put an indefinite lock on it, thereby preventing Apport from succesfully doing its work, again leading to service DoS for Apport. Apport DoS could also be achieved by for example creating /var/crash/.lock as a directory or as a socket file, meaning Apport can't os.open() /var/crash/.lock as a file, again making Apport fail (i.e., service DoS). The above scenarios prevent legitimate Apport processes from creating, opening and / or locking the lock file, leading to DoS for both invidual Apport instances as well as Apport as a whole, i.e., service DoS. Note that the impact of this issue might be even worse on systems without sysctl(8)'s "fs.protected_symlinks=1" set, which in default installations provides effective protection due to /var/crash/ being a sticky directory, or without "fs.protected_hardlinks=1" being set. Also note that, besides all of the impacts above due to /var/crash/ being world-writable, /var/crash/ isn't a logical location to place a lock file to begin with; using a more appropriate location like /var/lock/ would make more sense, and is also the proposed fix for this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/apport/+bug/1839415/+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