Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trivially exploitable priviledge escalation to root vulnerability #113

Closed
koraa opened this issue Dec 21, 2021 · 16 comments
Closed

Trivially exploitable priviledge escalation to root vulnerability #113

koraa opened this issue Dec 21, 2021 · 16 comments

Comments

@koraa
Copy link
Contributor

koraa commented Dec 21, 2021

The way GlobalProtect-Openconnect is set up enables arbitrary users to execute commands as root:

  1. Install the payload; in this case, a demonstration payload installing itself to /usr/bin/GROOT

     echo -e '#!/bin/bash\ncat "$0" > /usr/bin/GROOT\nchmod a+x "$0" /usr/bin/GROOT' > /tmp/groot; bash /tmp/groot
    
  2. Specify openconnect parameters: --script=/tmp/groot

  3. Log into any VPN service

This vulnerability can be executed by any user, even a "nobody" user covertly by sending commands to the com.yuezk.qt.GPService.
This vulnerability can be executed by a user with keyboard access to install a rootkit using the GUI you provided.
This vulnerability can be executed as soon as openconnect-globalprotect is installed; even if the gpservice.service systemd service has not been started as the unit file specifies: BusName=com.yuezk.qt.GPService. I had to explicitly mask the service to mitigate the vulnerability.

As such, it leaves any host who even has the program installed highly vulnerable; this is the worst case among privilege escalation vulnerabilities.

For a secure-by-default configuration, openconnect-global needs to be updated, so administrator approval is needed to allow specific globalprotect servers or a change in command line parameters.

I propose a root-editable configuration file /etc/openconnect-globalprotect.conf with the following syntax

  karolin *.vpn.cupdev.net -i cupdev --script=/etc/vpn/cupdev-ifup.sh

This entry allows the user karolin to connect to any vpn servers with a domain suffix vpn.cupdev.net and the specified openconnect parameters.
Groups may be specified by prefixing the user with %.

The app could implement a config-editing feature, allowing users to edit the configuration graphically after specifying the administrator password.

I would also suggest disabling systemd dbus activation altogether just to avoid the entire issue of a security bug sticking around even with a stopped unit.

Thank you for all your hard work!

@koraa koraa changed the title Trivially Exploitable Priviledge Escalation Vulnerability Trivially exploitable priviledge escalation to root vulnerability Dec 21, 2021
@yuezk
Copy link
Owner

yuezk commented Dec 22, 2021

@koraa Thanks for your solid advice. I will try to fix it.

@koraa
Copy link
Contributor Author

koraa commented Dec 22, 2021

@yuezk Feel free to ping me any time; I'll be happy to perform a security review of the fix or answer any questions that may arise!

@yuezk
Copy link
Owner

yuezk commented Dec 26, 2021

> I would also suggest disabling systemd dbus activation altogether just to avoid the entire issue of a security bug sticking around even with a stopped unit.

  1. It should be easy to disable the dbus activation, by just modifying the unit file.
  2. I'm wondering if it is secure if I made it an auto-starting service as the root user.

@yuezk
Copy link
Owner

yuezk commented Dec 26, 2021

Hi @koraa, below is my understanding, correct me if I were wrong. Thanks.

  1. Provide a root-editable configuration file.
  2. The GPService runs in the background should not accept the custom parameters pass to the OpenConect CLI. Instead, it should read the parameters configured in the root-editable configuration file. And validate the user who wants to connect to the VPN server is specified in the configuration file.
  3. Do I still need to disable the DBus activation after 1 & 2 are implemented?

@koraa
Copy link
Contributor Author

koraa commented Dec 26, 2021

That sounds good. I would still disable dbus activation, yes.
DBus activation is generally a bad idea as it magnifies security issues; a user should always opt into a service starting, not opt out as they would with DBus activation.

@la2fda
Copy link

la2fda commented Jan 10, 2022

Thanks for a really god job, but #113 is unfortunately a showstopper for my organization.
Is there any progress ?

@koraa
Copy link
Contributor Author

koraa commented Jan 10, 2022

@la2fda (Check out my #110 scripting mode, it can be used as a stopgap measure; fetch the ticket as a normal user and use sudo to run the actual openconnect session…it's a bit of work but it's much safer and works nicely)

@koraa
Copy link
Contributor Author

koraa commented Apr 22, 2022

@yuezk
Copy link
Owner

yuezk commented Apr 25, 2022

The OpenConnect extension for Gnome doesn't require the root privilege. I will refer to its implementation.
I also did some investigation on Running OpenConnect as a non-root user. Will try my best to fix it ASAP.

@yuezk
Copy link
Owner

yuezk commented May 9, 2022

@koraa I moved the configuration to /etc/gpservice/gp.conf in 1.4.3.

❯ ls -l /etc/gpservice/gp.conf       
-rw-r--r-- 1 root root 423  5月  8 21:42 /etc/gpservice/gp.conf

More details about the configuration can be found at https://github.com/yuezk/GlobalProtect-openconnect/wiki/Configuration.

Do you have any concerns about it?

@koraa
Copy link
Contributor Author

koraa commented May 10, 2022

@yuezk That sounds good! Where was it before?

@yuezk
Copy link
Owner

yuezk commented May 10, 2022

Previously, the extra arguments for OpenConnect are configured in the settings dialog (the values are saved in ~/.config/com.yuezk.qt folder) and passed to the gpservice. Now I removed the ability to pass the extra args, and gpservice will read it from /etc/gpservice/gp.conf

At the same time, the user can edit gp.conf with the root permission manually to tune the args, instead of editing them in the settings dialog with a normal user permission.

@koraa
Copy link
Contributor Author

koraa commented May 11, 2022

That sounds like a good fix to me!

@yuezk yuezk closed this as completed May 14, 2022
@yuezk
Copy link
Owner

yuezk commented May 14, 2022

Fixed in 1.4.3

@TS-CUBED
Copy link

Does this fix https://nvd.nist.gov/vuln/detail/CVE-2021-45809 ?

If yes, it may be worth updating the CVE to indicate that this is fixed in v>1.4.3

@yuezk
Copy link
Owner

yuezk commented Jun 13, 2022

@TS-CUBED Yes. Just submitted the request for updating the description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants