Bugzilla – Bug 1165802
VUL-0: CVE-2020-10174: timeshift: arbitrary local code execution due to unsafe usage of temporary directory in /tmp/timeshift
Last modified: 2020-03-06 09:01:25 UTC
The audit I did for bug 1165436 uncovered a local root exploit present in Timeshift. I informed the upstream author privately by mail yesterday sharing the following information: > The problem is found in TeeJee.Process.vala [3]. There in `init_tmp()` a > temporary directory for use by the timeshift program is setup. The > TEMP_DIR path is setup like this: > > ``` > TEMP_DIR = Environment.get_tmp_dir() + "/" + subdir_name + "/" + > random_string(); > ``` > > This results in a path like /tmp/timeshift/wytOlUJg, for example. Only > the last part of the path is unpredictable, the /tmp/timeshift > directory, however, is static and fully predictable. timeshift does not > perform any checks regarding the trustworthyness of a pre-existing > /tmp/timeshift directory, or whether it might be a symlink. A typical > no-op run of timeshift causes the following system call sequence: > > ``` > [pid 2676] lstat("/tmp/timeshift/L00qsHH5", 0x7fffb14adfd0) = -1 ENOENT > (No such file or directory) > [pid 2676] mkdir("/tmp/timeshift/L00qsHH5", 0777) = 0 > [pid 2676] lstat("/tmp/timeshift/L00qsHH5/15833214581345651125.sh", > 0x7fffb14adf10) = -1 ENOENT (No such file or directory) > [pid 2676] openat(AT_FDCWD, > "/tmp/timeshift/L00qsHH5/15833214581345651125.sh", O_WRONLY|O_CREAT|O_EXCL, > 0666) = 7 > [pid 2679] execve("/usr/bin/chmod", ["chmod", "u+x", > "/tmp/timeshift/L00qsHH5/15833214"...], 0x7fffb14ae3f0 /* 63 vars */ > <unfinished ...> > [pid 2679] stat("/tmp/timeshift/L00qsHH5/15833214581345651125.sh", > {st_mode=S_IFREG|0644, st_size=102, ...}) = 0 > [pid 2679] fchmodat(AT_FDCWD, > "/tmp/timeshift/L00qsHH5/15833214581345651125.sh", 0744) = 0 > [pid 2680] chdir("/tmp/timeshift/L00qsHH5") = 0 > [pid 2680] execve("/tmp/timeshift/L00qsHH5/15833214581345651125.sh", > ["/tmp/timeshift/L00qsHH5/15833214"...], 0x55f02814cfe0 /* 63 vars */ > <unfinished ...> > ``` > > The `execve()` at the end is the result of the line > `exec_script_sync("echo 'ok'",out std_out,out std_err, true)` which is > also part of the `init_tmp()` function. > > An unprivileged attacker can pre-create the `/tmp/timeshift` directory > and wait for a timeshift process running as root to create the > unpredictable sub-directory /tmp/timeshift/L00qsHH5 and shell script in > 15833214581345651125.sh there. Then the attacker only needs to replace > this directory and script by his own ones in time, resulting in > arbitrary code execution as root. > > A very simple proof of concept to show the problem is what happens when > a symlink is placed in /tmp/timeshift: > > ``` > user $ ln -s /root /tmp/timeshift > ``` > > This will cause timeshift to create temporary data in /root instead of > in /tmp. > > For fixing this issue I suggest to remove the predictable prefix (in > this case "timeshift") from the TEMP_DIR path. Also the unpredictable > temporary directory created by timeshift should not be world readable > i.e. it should get mode 0750 to prevent that other users in the system > might obtain sensitive temporary data from the timeshift execution. > Currently these directories are created with mode 0755 by timeshift (or > more precisely, the mode is only modified by the calling user's umask, > which is 0022 by default). The upstream author right away publically fixed the issue in [1]. Therefore there is no need to formally establish an embargo. [1]: https://github.com/teejee2008/timeshift/commit/335b3d5398079278b8f7094c77bfd148b315b462
@malcolmlewis@cableone.net: so before I can whitelist the timeshift polkit actions you need to package a safe version of Timeshift. Either use the new release (v20.03) that upstream made. Or you can backport the bugfix commit referenced in comment 0 into the current version you have. SUSE products should not currently be affected by this since this is a new package not even in Factory.
Hi, this issue has been addressed in Submit Request https://build.opensuse.org/request/show/781867
Mitre assigned CVE-2020-10174 to track this issue.