Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230329133450.GK21675@suse.com>
Date: Wed, 29 Mar 2023 15:34:50 +0200
From: Johannes Segitz <jsegitz@...e.de>
To: oss-security@...ts.openwall.com
Subject: polkitd service user privilege separation

Hello,

I'm a member of the SUSE product security team. During the product audit
for SLES 15 SP5 I noticed an issue with polkit:

# Default rules config writeable for the service user

polkit stores rules in /etc/polkit-1/rules.d. We follow the upstream
provided permissions for this folder, so polkitd owns it and permissions
are set to 700:

localhost:/etc/polkit-1/rules.d # ls -lah
total 64K
drwx------ 1 polkitd root  44 Mar  8 18:29 .
drwxr-xr-x 1 root    root  14 Mar  8 17:16 ..
-rw-r--r-- 1 root    root 64K Mar  8 17:18 90-default-privs.rules

Since the user owns the directory it's easy to escalate from user polkitd
to root. The user can create own rules that are interpreted by the polkit
authority which in turn grants root privileges via e.g. the setuid-root
binary pkexec.

# POC

To show the impact of this get access to a shell running as polkitd. The
easiest way is to spawn a root shell, then change into the polkitd user:

root $ sudo -u polkitd /bin/sh
polkitd $ id
uid=475(polkitd) gid=475(polkitd) groups=475(polkitd)
polkitd $ pkexec id
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
Authentication is needed to run `/usr/bin/id' as the super user
Authenticating as: root
Password:

So with the default rules the root password would be required. Since the
rules directory is writeable we can add a rule that allows everything:

polkitd $ echo 'polkit.addRule(function(action, subject) { return "yes"; });' > /etc/polkit-1/rules.d/00-allow-all.rules
polkitd $ pkexec id
uid=0(root) gid=0(root) groups=0(root)

This demonstration caused some confusion in the original report to
upstream. The POC is here to demonstrate the issue, not how real world
exploitation would work. A real world exploit would rely on another
vulnerability to be able to act as polkitd and then use the issue outlined
here to escalate privileges.

# Proposed solution

If you can act as the polkitd user you can also likely influence the polkit
daemon and gain root this way, so this just makes it (a lot) easier to exploit.
I still think it's worthwhile to keep the user for the daemon and not run it as
root.

For existing installations change the permissions of
- /etc/polkit-1/rules.d
- /usr/share/polkit-1/rules.d
to root:polkitd, 750 to make it harder to gain root privileges.

SELinux or other more fine-grained control could be used to make escalating
to root harder, by restricting the amount of freedom polkitd has. But in
the end it's probably not possible to fully prevent this.

Currently the documentation raises the expectation that there's a security
boundary (man polkit):
The polkit authority is implemented as an system daemon, polkitd(8), which
itself has little privilege as it is running as the polkitd system user.

Through this posting I wanted to raise awareness that the polkitd user in a
default installation is equivalent to root without any further counter
measures. In my opinion this should be stated in the man pages so that
users are aware of this. At the moment most people would likely assume that
the user serves a similar roles as other service users.

# Communication with upstream

- 2023-03-09: Informed upstream via confidential ticket:
  https://gitlab.freedesktop.org/polkit/polkit/-/issues/191
- 2023-03-15: Proposed documentation fix, not merged
  https://gitlab.freedesktop.org/polkit/polkit/-/issues/191#note_1824052
- 2023-03-21: Partial fix for the permission in
  https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/153
- 2023-03-29: Issue is public

Johannes
-- 
GPG Key                EE16 6BCE AD56 E034 BFB3  3ADD 7BF7 29D5 E7C8 1FA0
Subkey fingerprint:    250F 43F5 F7CE 6F1E 9C59  4F95 BC27 DD9D 2CC4 FD66
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
(HRB 36809, AG Nürnberg)

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.