A flaw was found in PolicyKit (aka polkit) 0.115 that allows a user with a uid greater than INTMAX to successfully execute any systemctl command.

A Local Privilege Escalation vulnerability (from any user to root) was found in polkit's pkexec, a SUID-root program that is installed by default on every major Linux distribution.

It was found that polkit could be tricked into bypassing the credential checks for D-Bus requests, elevating the privileges of the requestor to the root user. This flaw could be used by an unprivileged local attacker to, for example, create a new local administrator. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in polkit before version 0.116. The implementation of the polkitbackendinteractiveauthoritycheckauthorization function in polkitd allows to test for authentication and trigger authentication of unrelated processes owned by other users. This may result in a local DoS and information disclosure.

Race condition in PolicyKit (aka polkit) allows local users to bypass intended PolicyKit restrictions and gain privileges by starting a setuid or pkexec process before the authorization check is performed, related to (1) the polkitunixprocessnew API function, (2) the dbus API, or (3) the --process (unix-process) option for authorization to pkcheck.

In PolicyKit (aka polkit) 0.115, the "start time" protection mechanism can be bypassed because fork() is not atomic, and therefore authorization decisions are improperly cached. This is related to lack of uid checking in polkitbackend/polkitbackendinteractiveauthority.c.

There is a flaw in polkit which can allow an unprivileged user to cause polkit to crash, due to process file descriptor exhaustion. The highest threat from this vulnerability is to availability. NOTE: Polkit process outage duration is tied to the failing process being reaped and a new one being spawned

It was reported that polkit has a bug, that leads to a minor denial of service, or code execution/privilege escalation. The only privilege necessary is ability to send D-Bus messages, not even necessarily directly to polkitd (usually privileged services ask polkitd for authorization based of a client request: client<->D-Bus<->service<->D-Bus<->polkitd); the attacker does not need special polkit status. This bug allows a local user (a person on a multi-user system, or a daemon account after successfully attacking a daemon over the network) to corrupt memory of polkitd. Corrupting polkitd memory can lead to a crash (known to happen), which is a minor DoS: a specific request being handled during the crash will not get a reply, but polkitd will then be automatically started when next polkit request arrives. In general corrupting memory can lead to arbitrary code execution as polkitd (no proof of concept exists but I can see no reason for this to be impossible), controlling polkitd allows the attacker to grant to anyone access to any polkit-controlled service, including the ability to run any command as root via pkexec.

Initially reported in https://bugzilla.redhat.com/showbug.cgi?id=910262 The patches are attached.

Integer overflow in the authenticationagentnewcookie function in Po ...

It was reported that if polkit, while reading action descriptions from /usr/share/polkit-1/actions, encounters a duplicate action ID, it corrupts the heap. The effects of corruption are e.g. visible on stderr as frequent use of unrelated strings when running polkit without --no-debug.

Presumably a local attacker might be able to manipulate polkit’s heap enough to achieve privilege escalation through this.

Upstream bug: https://bugs.freedesktop.org/showbug.cgi?id=83590 Upstream patch is attached.

Last updated 24 July 2024