Linux privilege escalation via LXD
Members of the local lxd group on Linux systems have numerous routes to escalate their privileges to root. This repository contains examples of fully automated local root exploits. A detailed explanation of the vulnerability and an exploit walk-through is available in my blog here.
The exploits below are not container break-outs, but local root exploits that leverage containers and target the host OS. Low-privilege access to the host environment is required for successful exploitation.
I believe my strategy with version 2 of the exploit is unique, and was interesting enough (to me at least) to write a detailed explanation in the blog linked above.
lxd_rootv1.shmounts the host
/filesystem into a container, where the host's low-privilege user has root access. This root access maps back to the host, allowing the current user to be added to the /etc/sudoers file. This has been exploited by others before me.
lxd_rootv2.pymounts the host's systemd private UNIX socket into a container and then back to the host again via LXD proxy devices. These proxy devices have root privileges, and they pass their credentials during socket communications, as opposed to the credentials of the initiating low-privilege user. This is abused to create a temporary systemd service that adds the current user to the /etc/sudoers file.
Both exploits require a container, so make one first. Then, run the exploit from the host OS with the name of the container as the first argument.
# Exploit with v1 $ bash lxd_rootv1.sh <container name> # Exploit with v2 $ python3 lxd_rootv2.py <container name>
Package Maintainter Response
Before I came across these issues, nothing in the official LXD documentation existed to warn users that the
lxd group was dangerous. Anyone following the official guidelines to configure LXD would have added their account into this group before deploying their first container. I opened a bug with Canonical to express my concerns - you can read the full thread here. The LXD team quickly made adjustments to the documentation, which now clearly states that this group should only be given to those trusted with root access.
As always, interacting with the Canonical folks via their bug tracker was a really pleasant experience. I'd like to thank them for their time and for the thoughtful consideration they gave my ideas. I highly recommend other security researchers bring items directly to them in this manner.