Bug 1165802 (CVE-2020-10174) - VUL-0: CVE-2020-10174: timeshift: arbitrary local code execution due to unsafe usage of temporary directory in /tmp/timeshift
Summary: VUL-0: CVE-2020-10174: timeshift: arbitrary local code execution due to unsaf...
Status: RESOLVED FIXED
Alias: CVE-2020-10174
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security (show other bugs)
Version: Current
Hardware: Other Other
: P3 - Medium : Normal (vote)
Target Milestone: ---
Assignee: Malcolm Lewis
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 1165436
  Show dependency treegraph
 
Reported: 2020-03-05 11:28 UTC by Matthias Gerstner
Modified: 2020-03-06 09:01 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Gerstner 2020-03-05 11:28:53 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
Comment 1 Matthias Gerstner 2020-03-05 11:32:10 UTC
@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.
Comment 2 Malcolm Lewis 2020-03-05 14:01:22 UTC
Hi, this issue has been addressed in Submit Request https://build.opensuse.org/request/show/781867
Comment 3 Matthias Gerstner 2020-03-06 09:01:10 UTC
Mitre assigned CVE-2020-10174 to track this issue.