Hypothetical privilege escalation if polkitd user ever hijacked

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jsegitz on Mar 9, 2023, 14:03

Link to the original issue: https://gitlab.freedesktop.org/polkit/polkit/-/issues/191 During an product audit I noticed this:

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 polkitd owns the directory it's easy to escalate to root. POC:

sh-4.4$ id
uid=475(polkitd) gid=475(polkitd) groups=475(polkitd)
sh-4.4$ pkexec id
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
Authentication is needed to run `/usr/bin/id' as the super user
Authenticating as: root
Password:
sh-4.4$ echo 'polkit.addRule(function(action, subject) { return "yes"; });' > /etc/polkit-1/rules.d/00-allow-all.rules
sh-4.4$ pkexec id
uid=0(root) gid=0(root) groups=0(root)

If you can act as polkitd you can also likely influence the polkit daemon, so this just makes it easier to exploit. I think it's worthwhile to keep the user for the daemon. The main issue is that 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.

The polkitd user is basically root. That should be clearly explained.

I don't think that this needs a CVE.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jsegitz on Mar 13, 2023, 11:36

Also the permissions of the directory should be changed to owner root, group for polkitd and then have something like 750 set there

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jrybar on Mar 14, 2023, 17:25

Hello,

well, yeah, it's quite possible to do everything if you manage to login as 'polkitd' user, however, polkitd shall be 'nologin' in /etc/passwd as every system daemon, hence it should be impossible. Can I ask how you managed to log in as 'polkitd'?

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jrybar on Mar 14, 2023, 17:30

ANYWAY, thank you for posting this and using 'Confidential' issue. I really appreciate it and thank you for any time you've invested in this.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jsegitz on Mar 15, 2023, 08:05

For testing I do this with sudo, that way nologin doesn't matter.

The idea is not to login as that user, but to use a security issue to gain code execution as polkitd. It's a common pattern to not run services as root to prevent immediate code execution as root in cases like this. polkit does the same, which is good. But due to the way the permissions are set (and additionally the ability to influence the daemon) this separation doesn't work here. But it's stated in the man page that it does. So this really is mainly a problem of mislead expectations. Users need to be aware that the polkitd user is basically root, there is no security boundary.

Also the way the permissions are currently set it makes escalation a lot easier than it needs to be.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jrybar on Mar 15, 2023, 14:13

But once a user is in the sudoers file, it doesn't matter. The mechanism stands on the fact that only 'root' and 'polkitd' can edit the files owned by 'polkitd', also you cannot log in as 'polkitd'.
Sorry, I still don't see a potential attack vector.

The polkitd user is basically root. That should be clearly explained. polkitd binary is SUID, but dropsit soon after start. Discussing the need for this with former team members.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jsegitz on Mar 15, 2023, 14:28

sudo is just for testing, that is not the attack vector.

The attack works like this: You find an issue that gives you the ability to act as polkitd => immediate root at the moment.

Look at the same for other daemons e.g. postfix: You find an issue that gives you the ability to act as postfix => low privileged user, you're not root on the system.

The man pages makes it sound like this is the case here too. It needs to be spelled out that the polkitd user is root and is only there as a slim hardening measure.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jrybar on Mar 15, 2023, 16:21

Definitely not this case.
You cannot act as polkitd because, like I said, it has 'nologin' shell assigned in /etc/passwd. You cannot log in as polkitd. You cannot even run a command as polkitd becuase that would require sudo, hence sudoers file, which makes this pointless. And like I said, polkitd drops SUID soon after it starts, so it's not root anymore (few milisecs after start). And I recalled why it's run as root in the systemd.unit, that is, it needs root to change its RUID+EUID to 'polkitd', otherwise it would run under the owner of the session. And this is needed so the process is unreachable to the owner of the session.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jsegitz on Mar 15, 2023, 16:45

It's not about login shells, sudo or anything like this. Let me try again to get my point across:

You have a vulnerability in a daemon, lets say again in postfix. It allows the attacker the privileges of the service user. Basically like many other security vulnerabilities. In this case the attacker only gains the privileges for the service user, not root. That's the reason why we run daemons not as root but as unprivileged users.

Now for polkit: You have a vulnerability in a polkit. It allows the attacker the privileges of the polkitd user. In this case the attacker has immediately root in the current configuration. The polkitd user didn't limit anything.

Do you see the difference? The other service users also have no shell etc., but that doesn't matter in the case where you exploit the service. The ability to limit the impact of an exploit is the reason for using service users. This isn't the case here.

And it likely can't be done since once the attacker has this level of control he can influence polkit to always answer "yes" to any auth request. In any other daemon that would be a CVE right away. Here it's not due to the functionality of the software. But you can't tell users that 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. Users must be told that the polkitd user is root.

Additionally the permission setup for /etc/polkit-1/rules.d reduces security and serves no purpose (but maybe I just don't understand it).

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jrybar on Mar 15, 2023, 17:38

Users must be told that the polkitd user is root.

But polkitd user is NOT root: https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/src/polkitbackend/polkitd.c#L207

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jsegitz on Mar 15, 2023, 17:59

I understand that you drop privileges. But the POC shows that the user can easily get them back.

Would it be possible to bring in a member of the RH security team into the discussion?

[polkit-github-migration-bot]

In gitlab.freedesktop.org by halfline on Mar 15, 2023, 19:57

@jsegitz can you post here a patch to polkitd.xml and polkit.xml that adds the clarification of the blurred security boundary, you'd like mentioned?

EDIT: Maybe something like this?

diff --git a/docs/man/polkit.xml b/docs/man/polkit.xml
index 90715a5..8e8f675 100644
--- a/docs/man/polkit.xml
+++ b/docs/man/polkit.xml
@@ -42,3 +42,7 @@
       and authentication agents communicate with the authority using
-      the system message bus.
+      the system message bus. Because mechanisms, themselves, may be
+      running with elevated privilges, and those mechanisms trust
+      the <emphasis>polkitd</emphasis> system user, it's important
+      to note that a bug in <emphasis>polkitd</emphasis> can still
+      indirectly lead to privilege escalation.
     </para>
diff --git a/docs/man/polkitd.xml b/docs/man/polkitd.xml
index 5fee8d4..d07a0a4 100644
--- a/docs/man/polkitd.xml
+++ b/docs/man/polkitd.xml
@@ -45,3 +45,7 @@
       privileges but drops privileges early by switching to the
-      unprivileged <emphasis>polkitd</emphasis> system user.
+      <emphasis>polkitd</emphasis> system user. Note, while the
+      <emphasis>polkitd</emphasis> system user is running ostensibly
+      unprivileged, it is trusted by code that may be running with elevated
+      privileges. This trust relationship means, e.g., an exploit
+      in polkitd could still lead to privilege escalation.
     </para>

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jsegitz on Mar 16, 2023, 12:27

yes, that looks great, thanks :smile:

That leaves the directory permissions. Do you see any reason not to change the permissions for /etc/polkit-1/rules.d to either polkitd:root 570 or root:polkitd 750 That makes exploitation harder, because polkitd can't directly write new rules but needs to go the extra step of influencing the running process

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jrybar on Mar 16, 2023, 12:39

user can easily get them back

Once a process changes its euid/ruid from root to regular user, it cannot go back because that needs root. That's the point.

You still haven't explained how you managed to login as polkitd as your POC builds on it and it seems impossible with the current implementation.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jsegitz on Mar 16, 2023, 13:02

sudo -u polkitd /bin/sh
sh-4.4$ id
uid=497(polkitd) gid=496(polkitd) groups=496(polkitd) context=unconfined_u:unconfined_r:unconfined_t:s0

So this is a proof of concept. I'm fully aware that I can't log in as this user the normal way and that going from root to this users obviously isn't realistic. This is done purely to allow me to show the impact, nothing else.

In the real world an attacker would exploit polkitd, spawn a shell once he has code execution (here it doesn't matter if nologin is specified) and then do the next steps I showed.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jrybar on Mar 16, 2023, 13:02

Thanks, Ray. This patch helped me to finally realize that this entire Issue is strictly hypothetical, regardless the PoC.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by halfline on Mar 16, 2023, 22:18

offhand i can think of no reason the polkitd user would want to write to /etc/polkit-1/rules.d at runtime

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jsegitz on Mar 17, 2023, 07:38

Good. root:polkitd 750 would be better since this doesn't require changes to SELinux policies

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jrybar on Mar 21, 2023, 18:24

Resolved in !153

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jsegitz on Mar 22, 2023, 07:39

The documentation change is still missing. Also can you please make this issue public?

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jsegitz on Mar 24, 2023, 10:07

ping :)

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jrybar on Mar 27, 2023, 15:54

As not a member of a security team, I'm not fully aware of the common practice, but saying sth like "it is an authentication/authorization daemon, hijacking might lead to priv. escalaction" seems like stating the obvious to me. Is that really necessary? (i.e. "much ado about nothing" situation?)

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jsegitz on Mar 28, 2023, 08:47

well, at the moment you state the opposite in your man pages, so I think it is necessary. But I leave it up to you how you want to handle this, but would ask you to open this bug so that this is visible to community members.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jrybar on Mar 29, 2023, 08:27

made the issue visible to everyone

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jrybar on Mar 29, 2023, 09:10

Changing the permissions of configuration files seems reasonable, but then it's harder to find a reason for extending the security notice in the documentation. Again, stating that hijacking a system daemon leads to a security situation seems pointless.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jsegitz on Mar 29, 2023, 13:06

!153 sill leaves pkgsysconfdir owned by polkitd. As long as some rules directory is writeable the POC will work.

Also I think the change to the man-page really is the more important part, since it builds up security expectations that can't be fulfilled in the current setup.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jrybar on Mar 29, 2023, 15:44

1. I don't really find making a note in documentation more important than removing the root cause in first place.
2. Saying that hacked authorization service is a threat is clear even without a mention in the documentation.

@jsegitz, please don't consider closing of this issue a sign of disrespect. I really appreciate this discussion and your enthusiasm and I hope there will be another insight from you in future. I just simply don't believe the change in documentation has to be made. But you've really convinced me in tweaking the permission of the remaining files. Thank you.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jrybar on Mar 30, 2023, 09:25

That's why it's decided to CHANGE THE SETUP https://gitlab.freedesktop.org/polkit/polkit/-/issues/194.