Discussion:
polkit CVE-2021-3560
(too old to reply)
John McCue
2021-06-11 19:28:07 UTC
Permalink
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
2021-06-11 19:55:37 UTC
Permalink
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.
--
Lew Pitcher
"In Skills, We Trust"
John McCue
2021-06-11 23:37:53 UTC
Permalink
<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
2021-06-12 13:54:13 UTC
Permalink
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
2021-07-06 01:24:20 UTC
Permalink
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
2021-07-06 05:25:29 UTC
Permalink
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
2021-07-07 22:25:07 UTC
Permalink
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.
--
----------------------------------------------------------------------
Sylvain Robitaille ***@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
Ralph Spitzner
2021-07-07 22:39:38 UTC
Permalink
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
2021-07-08 05:58:33 UTC
Permalink
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 ...
--
----------------------------------------------------------------------
Sylvain Robitaille ***@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
Ralph Spitzner
2021-07-08 06:37:55 UTC
Permalink
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
2021-07-10 17:35:55 UTC
Permalink
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
2021-07-10 19:24:57 UTC
Permalink
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
2021-07-10 20:01:50 UTC
Permalink
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
2021-07-10 22:42:38 UTC
Permalink
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
--
With respect,
= Aragorn =
Henrik Carlqvist
2021-07-12 05:19:14 UTC
Permalink
(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
2021-07-12 08:04:06 UTC
Permalink
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>
--
With respect,
= Aragorn =
Henrik Carlqvist
2021-07-12 18:00:01 UTC
Permalink
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
2021-06-12 14:48:03 UTC
Permalink
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.
--
Lew Pitcher
"In Skills, We Trust"
Loading...