[Pkg-utopia-maintainers] Bug#903563: polkit: CVE-2018-1116: polkitd trusting client-supplied UID allows spoofed authentication dialogs

[Simon McVittie]

Package: policykit-1
Version: 0.105-3+nmu1
Severity: important
Tags: security pending
X-Debbugs-Cc: security at debian.org

Security team: Do you want to do a DSA for this, or should this just be a
stable-update?

I've uploaded policykit-1/0.105-21 with a backport of the patch, but I'd
appreciate a check from other developers on whether I have backported it
correctly. I also have 0.115-1 ready for upload to experimental when I've
tested it.

I will have limited availability this/next week, so I would appreciate it
if someone else could prepare and test whatever security or stable updates
are felt to be appropriate.

Thanks,
    smcv

On Wed, 11 Jul 2018 at 10:21:56 +0200, Matthias Gerstner wrote:
> during a code reviewing related to polkit
> <https://www.freedesktop.org/wiki/Software/polkit/> I found a spoofed
> authentication vulnerability in the implementation of the polkitd
> daemon. It allows a local attacker to trigger authentication dialogs for
> other users' processes. This way the attacker can obtain certain
> information about the polkit rules configuration of other users, confuse
> other users or DoS other users by infinitely triggering authentication
> dialogs.
> 
> Basically the issue is that an attacker is able to specify
> arbitrary target process UIDs when talking to polkitd via D-Bus like
> this:
> 
> $ gdbus call --system --dest org.freedesktop.PolicyKit1 \
> 	--object-path /org/freedesktop/PolicyKit1/Authority \
> 	--method org.freedesktop.PolicyKit1.Authority.CheckAuthorization \
> 	'("unix-process", {"pid": <uint32 ${PID}>, "start-time": <uint64 0>, "uid": <${UID}>})' \
> 	org.freedesktop.timedate1.set-time '[]' 1 ''
> 
> Where ${PID} needs to be the process ID of the target process and ${UID}
> the user ID of the calling process i.e. `id -u`.
> 
> Upstream just released version 0.115 of polkit that addresses this issue
> by way of commit bc7ffad53643a9c80231fc41f5582d6a8931c32c. The issue was
> introduced with a fix for CVE-2013-4288 in polkit version 0.112.
> 
> Further below you can find the upstream commit message with a more
> detailed explanation of the issue and its fix. I want to thank the
> upstream developers for the constructive communication and quick
> handling of the issue.
> 
> Best regards
> 
> Matthias
> 
> Timeline:
> 
> 2018-06-21: I discovered and analyzed the issue
> 2018-06-22: I reported the issue privately to upstream via
>     dbus-security at lists.freedesktop.org. In the following days upstream
>     devised a patch that was discussed and reviewed on the mailing list.
>     Publication has been scheduled for 2018-07-10 together with the
>     release of the fixed polkit version.
> 2018-07-10: The upstream release was published as scheduled.
> 
> References:
> 
> - Upstream Release Notice: https://lists.freedesktop.org/archives/polkit-devel/2018-July/000583.html
> - Upstream Fix: https://cgit.freedesktop.org/polkit/commit/?id=bc7ffad53643a9c80231fc41f5582d6a8931c32c
> - SUSE Bug for the issue: https://bugzilla.suse.com/show_bug.cgi?id=1099031
> 
> Upstream Commit Message:
> 
>      Fix CVE-2018-1116: Trusting client-supplied UID
>       
>      As part of CVE-2013-4288, the D-Bus clients were allowed (and
>      encouraged) to submit the UID of the subject of authorization checks
>      to avoid races against UID changes (notably using executables
>      set-UID to root).
>      
>      However, that also allowed any client to submit an arbitrary UID, and
>      that could be used to bypass "can only ask about / affect the same UID"
>      checks in CheckAuthorization / RegisterAuthenticationAgent /
>      UnregisterAuthenticationAgent.  This allowed an attacker:
>      
>      - With CheckAuthorization, to cause the registered authentication
>        agent in victim's session to pop up a dialog, or to determine whether
>        the victim currently has a temporary authorization to perform an
>        operation.
>      
>        (In principle, the attacker can also determine whether JavaScript
>        rules allow the victim process to perform an operation; however,
>        usually rules base their decisions on information determined from
>        the supplied UID, so the attacker usually won't learn anything new.)
>      
>      - With RegisterAuthenticationAgent, to prevent the victim's
>        authentication agent to work (for a specific victim process),
>        or to learn about which operations requiring authorization
>        the victim is attempting.
>      
>      To fix this, expose internal _polkit_unix_process_get_owner() /
>      obsolete polkit_unix_process_get_owner() as a private
>      polkit_unix_process_get_racy_uid__() (being more explicit about the
>      dangers on relying on it), and use it in
>      polkit_backend_session_monitor_get_user_for_subject() to return
>      a boolean indicating whether the subject UID may be caller-chosen.
>      
>      Then, in the permission checks that require the subject to be
>      equal to the caller, fail on caller-chosen UIDs (and continue
>      through the pre-existing code paths which allow root, or root-designated
>      server processes, to ask about arbitrary subjects.)
>      
>      Signed-off-by: Miloslav Trmač <mitr at redhat.com>