polkit CVE-2021-3560

[John McCue]

Hi,

Please, no systemd rants :)

This is a rather simple question (I hope). In LWN seems
there is a polkit vulnerability article and it contains
this link:

TinyURL: https://tinyurl.com/tnsve57u
OR
https://github.blog/2021-06-10-privilege-escalation-polkit-root-on-linux-with-bug/

I reading both LWN and the link, they seem to hint it only
happens with systemd. Is that correct ? Or it is general
to polkit ?

I would think all Linux Systems are vulnerable no matter
its init (assuming they use polkit).

Thanks
John

[Lew Pitcher]

Post by John McCue
Hi,
Please, no systemd rants :)
This is a rather simple question (I hope). In LWN seems
there is a polkit vulnerability article and it contains
TinyURL: https://tinyurl.com/tnsve57u
OR
https://github.blog/2021-06-10-privilege-escalation-polkit-root-on-linux-with-bug/
I reading both LWN and the link, they seem to hint it only
happens with systemd. Is that correct ? Or it is general
to polkit ?
I would think all Linux Systems are vulnerable no matter
its init (assuming they use polkit).

The second URL you quoted included a video demonstrating the polkit bug using
only commandline tools available on Slackware (i.e. nothing that /required/
systemd).

It seems like polkit has a timing-sensitive issue around the communication of
an authorization request over dbus, where polkit takes a well-timed failure to
communicate with an authorization prompt (either a GUI prompt or a text prompt)
as proper confirmation of increased privileges.

In other words, if you initiate a request for an action that requires privilege
escalation (via a dbus command) and abort that action (by killing the command)
at a crucial moment before polkit requests authorization to escalate privileges,
polkit does not ask for privilege escalation authorization (treating that abort
as a confirmation of escalated privileges), and executes the requested action
under the escalated privileges.

This mode of failure doesn't look to me to be related to systemd.

[John McCue]

<snip>

Post by Lew Pitcher
This mode of failure doesn't look to me to be related to systemd.

Thanks, wanted to be 100% sure, I suspect/hoping it is a local
vulnerability

John

[Henrik Carlqvist]

Post by John McCue
<snip>

Post by Lew Pitcher
This mode of failure doesn't look to me to be related to systemd.

Thanks, wanted to be 100% sure, I suspect/hoping it is a local
vulnerability

The easiest way to get rid of the vulerability is of course to install
the patch if you are running Stable Slackware 14.2:

-8<---------------------------------
Mon Jun 7 18:53:49 UTC 2021
...
patches/packages/polkit-0.113-x86_64-3_slack14.2.txz: Rebuilt.
This update includes a mitigation for local privilege escalation
using
polkit_system_bus_name_get_creds_sync().
For more information, see:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3560
(* Security fix *)
-8<---------------------------------

Also for Slackware current the same issue has already been addressed.

regards Henrik

[Mike Small]

Post by Henrik Carlqvist

Post by John McCue
Thanks, wanted to be 100% sure, I suspect/hoping it is a local
vulnerability

The easiest way to get rid of the vulerability is of course to install
-8<---------------------------------
Mon Jun 7 18:53:49 UTC 2021
...
patches/packages/polkit-0.113-x86_64-3_slack14.2.txz: Rebuilt.
This update includes a mitigation for local privilege escalation
using
polkit_system_bus_name_get_creds_sync().
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3560
(* Security fix *)
-8<---------------------------------

That's what I did, mechanically, when the update was released but
reading your post got me in a nitpicky frame of mind. Technically, there
is a modestly easier way...

# removepkg -preserve /var/log/packages/polkit-*

So far so good.

But maybe not for everyone. Thought I'd relish in the extra freedom
provided by Slackware's easy going package manager. When would I want
the sort of program that links to things like polkit (and 20 other
desktop libraries probably) to transmit commands to a privileged
process, even if last month's security problem is patched? Is there any
function it serves that isn't better served by doas, su or sudo?

If something breaks I'll at least learn what use polkit has. It doesn't
seem to be needed by emacs, tor-browser, mpv, or ssh, which covers most
of what I do on this computer.

- Mike Sm.

[Henrik Carlqvist]

When would I want the sort of program that links to things like polkit
(and 20 other desktop libraries probably) to transmit commands to a
privileged process, even if last month's security problem is patched?

My guess is that it is intended for desktop environments, allowing normal
users to point and click to mount USB drives.

Is there any function it serves that isn't better served by doas, su or
sudo?

Su assumes that all users know the root password. Sudo needs to be
configured, on a multiuser system you probably do not want every user to
be able to run "sudo bash".

regardss Henrik

[Sylvain Robitaille]

Post by Henrik Carlqvist

Is there any function it serves that isn't better served by doas, su
or sudo?

Su assumes that all users know the root password.

Arguably, it assumes that every user authorized to use it (to become
root) knows the root password ...

Post by Henrik Carlqvist
Sudo needs to be configured, on a multiuser system you probably do not
want every user to be able to run "sudo bash".

Agreed.

[Ralph Spitzner]

Post by Sylvain Robitaille

Post by Henrik Carlqvist
Sudo needs to be configured, on a multiuser system you probably do not
want every user to be able to run "sudo bash".

Agreed.

my first command after a fresh install of any flavor of buntuian is usually

Post by Sylvain Robitaille
sudo su

:-)
-rasp

[Sylvain Robitaille]

Post by Ralph Spitzner
my first command after a fresh install of any flavor of buntuian is
usually >sudo su

Try that on Slackware, without first configuring sudo to permit it ...

[Ralph Spitzner]

Post by Sylvain Robitaille

Post by Ralph Spitzner
my first command after a fresh install of any flavor of buntuian is
usually >sudo su

Try that on Slackware, without first configuring sudo to permit it ...

I know, I'm using slackware since '99 :-)
this was coined for these systems *buntu that have no(or a disabled( root pw ....

-rasp

[Lew Pitcher]

Post by Ralph Spitzner

Post by Sylvain Robitaille

Post by Ralph Spitzner
my first command after a fresh install of any flavor of buntuian is
usually >sudo su

Try that on Slackware, without first configuring sudo to permit it ...

I know, I'm using slackware since '99 :-)
this was coined for these systems *buntu that have no(or a disabled( root pw ....

"sudo su" is so indicative of a Linux newbie.

Those "in the know" forego the extra process and use
sudo -i
instead.

[Ralph Spitzner]

Post by Lew Pitcher
"sudo su" is so indicative of a Linux newbie.
Those "in the know" forego the extra process and use
sudo -i
instead.

You're welcome.
congratulations for being able to read a man page...
on slackware I've never needed, nor used sudo.
So, what do I care about this command or it's options, when I'm just doing someone willing to try linux over Window$ ?
I just need it to apt this and apt that an get out of there without having to type a password a zillion times.


-rasp

[Lew Pitcher]

Post by Ralph Spitzner

Post by Lew Pitcher
"sudo su" is so indicative of a Linux newbie.
Those "in the know" forego the extra process and use
sudo -i
instead.

You're welcome.
congratulations for being able to read a man page...
on slackware I've never needed, nor used sudo.
So, what do I care about this command or it's options, when I'm just doing someone willing to try linux over Window$ ?
I just need it to apt this and apt that an get out of there without having to type a password a zillion times.

Oh? Did someone get up on the wrong side of the commandline this morning?

[Aragorn]

Post by Lew Pitcher

Post by Ralph Spitzner

Post by Sylvain Robitaille

Post by Ralph Spitzner
my first command after a fresh install of any flavor of buntuian
is usually >sudo su

Try that on Slackware, without first configuring sudo to permit it ...

I know, I'm using slackware since '99 :-)
this was coined for these systems *buntu that have no(or a
disabled( root pw ....

"sudo su" is so indicative of a Linux newbie.
Those "in the know" forego the extra process and use
sudo -i
instead.

Those in-the-know won't even use sudo [1] for starting an interactive
shell, because they will also not accept the sudo default configuration
of requiring only the invoking user's own password.

On my system, sudo requires the target user's password, and I use...

$ su -

... to get an interactive root shell. (All direct root logins are
disabled here except in single-user maintenance mode, which requires
entering the root password.)


[1] Those in-the-know won't even be running Ubuntu or Mint, for that
matter, because those two distributions [2] are way too focused on
attracting Windows users and placating them in their Windows habits.

[2] They are unfortunately not the only ones, and the fact that most of
the GNU/Linux developers in 2021 [3] grew up on Microsoft Windows
and smartphones isn't exactly helping. ("Those who don't understand
UNIX are doomed to reinvent it — poorly.")

[3] Or 3187 for the worshipers of Our Lady of Discord. :D

[Henrik Carlqvist]

(All direct root logins are disabled here except in single-user
maintenance mode, which requires entering the root password.)

How did you configure that? Different /etc/securetty in single-user mode?
Disabling ctrl-alt-f1 in xorg.conf? Some other setting?

regards Henrik

[Aragorn]

Post by Henrik Carlqvist

(All direct root logins are disabled here except in single-user
maintenance mode, which requires entering the root password.)

How did you configure that? Different /etc/securetty in single-user
mode? Disabling ctrl-alt-f1 in xorg.conf? Some other setting?

I've completely emptied /etc/securetty, which takes care of all local
root logins in any of the normal runlevels, as well as root logins via
the serial port.

The file is not sourced for going to single-user mode, so it still
allows a root login then. Actually, single-user mode doesn't even ask
for a user name — only for the root password — and if you hit Ctrl+D
instead (as prompted) then it'll just return to the default runlevel
(or stay in the default runlevel on systemd-based distributions —
systemd runlevels work slightly differently).

And of course, if you want to disable root logins altogether, then you
will also want to do so in /etc/ssh/sshd_config. Many distributions —
though not all — do allow remote root logins by default, albeit only via
authentication keys. But given how many of those ssh keys are stored on
laptops that get stolen from remote sysadmins, it's no wonder that many
sites are getting compromised.

Much safer to log in with an unprivileged account and then use "su -"
to obtain root privileges. And of course, never allow GUI logins as
root. I don't think Slackware does that,but many distributions do, and
the n00bs are all too eager to go there, mess up their system and then
come to us for help in fixing it. <rolling eyes>

[Henrik Carlqvist]

Post by Aragorn

Post by Henrik Carlqvist

(All direct root logins are disabled here except in single-user
maintenance mode, which requires entering the root password.)

How did you configure that? Different /etc/securetty in single-user
mode? Disabling ctrl-alt-f1 in xorg.conf? Some other setting?

I've completely emptied /etc/securetty, which takes care of all local
root logins in any of the normal runlevels, as well as root logins via
the serial port.
The file is not sourced for going to single-user mode, so it still
allows a root login then.

Ah, /etc/securetty does not apply in single user mode!

Post by Aragorn
And of course, if you want to disable root logins altogether, then you
will also want to do so in /etc/ssh/sshd_config. Many distributions —
though not all — do allow remote root logins by default, albeit only via
authentication keys. But given how many of those ssh keys are stored on
laptops that get stolen from remote sysadmins, it's no wonder that many
sites are getting compromised.

Yes, allowing ssh login with password for root to a machine with the ssh
port open to internet is only a question of how long time it will take
until the root password has been brute force guessed.

Post by Aragorn
Much safer to log in with an unprivileged account and then use "su -"
to obtain root privileges.

Absolutely, the root shell is far to powerful for a daily driver. A tiny
mistake can make a big disaster.

regards Henrik

[Lew Pitcher]

Post by John McCue
<snip>

Post by Lew Pitcher
This mode of failure doesn't look to me to be related to systemd.

Thanks, wanted to be 100% sure, I suspect/hoping it is a local
vulnerability

Note that, while the vunerability is "local" to the system, an
attacker can trigger it from within an ssh session. Thus, the
attacker /does not have to be local/ to the system in order to
exploit this attack.