Your message dated Wed, 11 Jul 2018 12:21:07 +0100
with message-id <>
and subject line Re: Bug#903563: polkit: CVE-2018-1116: polkitd trusting 
client-supplied UID allows spoofed authentication dialogs
has caused the Debian Bug report #903563,
regarding polkit: CVE-2018-1116: polkitd trusting client-supplied UID allows 
spoofed authentication dialogs
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact

Debian Bug Tracking System
Contact with problems
--- Begin Message ---
Package: policykit-1
Version: 0.105-3+nmu1
Severity: important
Tags: security pending

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

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.


On Wed, 11 Jul 2018 at 10:21:56 +0200, Matthias Gerstner wrote:
> during a code reviewing related to 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
> 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: 
> - Upstream Fix: 
> - SUSE Bug for the issue:
> 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─Ź <>

--- End Message ---
--- Begin Message ---
Version: 0.105-21

On Wed, 11 Jul 2018 at 12:09:28 +0100, Simon McVittie wrote:
> I've uploaded policykit-1/0.105-21 with a backport of the patch


--- End Message ---

Reply via email to