Bug ID 1032717
Summary VUL-0: backintime: usage of deprecated unix-process polkit authorization subject opens a race condition during authorization
Classification openSUSE
Product openSUSE Distribution
Version Leap 42.2
Hardware Other
OS Other
Status NEW
Severity Normal
Priority P5 - None
Component Security
Assignee masterpatricko@gmail.com
Reporter matthias.gerstner@suse.com
QA Contact qa-bugs@suse.de
CC hrvoje.senjan@gmail.com, matthias.gerstner@suse.com
Found By ---
Blocker ---

backintime includes a DBus service helper 'qt/serviceHelper.py'. This helper
uses polkit to authorize some of its APIs, they should only be accessible
through entering the root password. The helper program uses the deprecated
"unix-process" authorization subject for this purpose, however. This polkit
authorization method is known to be affected by a "time of check, time of use"
race condition:

https://www.freedesktop.org/software/polkit/docs/latest/PolkitUnixProcess.html#polkit-unix-process-new
https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack/blob/master/2011/CVE-2011-1485/polkit-pwnage.c

To exploit this issue an attacker needs to be able to replace the PID of
process that requests an affected polkit privilege by a root owned process,
just in time for polkitd to assume that the requesting process was privileged
and no further password entry is required.

In the worst case this could allow a regular user to add udev rules to the
system that run commands in the context of the regular user, once a certain
udev event occurs. I don't think it is easily possible to gain root privileges
this way. This is because the serviceHelper wraps the udev commands in a sudo
call running as the user owning the requesting process. The determination of
this identity is done in a different, more secure way.

I've proposed a fix to upstream that changes the authorization mechanism to
"system-bus-name" which is considered safe and not affected by the described
race condition:

https://github.com/bit-team/backintime/commit/7f208dc547f569b689c888103e3b593a48cd1869

This issue was discovered by Sebastian Krahmer of the SUSE security team.


You are receiving this mail because: