Package: policykit-1
Version: 0.105-3+nmu1
Severity: important
Tags: security pending
X-Debbugs-Cc: secur...@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-secur...@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č <m...@redhat.com>
_______________________________________________
Pkg-utopia-maintainers mailing list
Pkg-utopia-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
