Privilege escalation via LXD (local root exploit)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
lxd (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
Hello Ubuntu team,
I'm a big fan of the LXD snap and am quite enjoying the technology. Below is a brief write-up of an issue I believe you may want to review. Thanks for your time and your hard work on such an amazing OS.
Any member of the local `lxd` group can immediately escalate their privileges to root on the host operating system. This is regardless of whether or not that user has been granted sudo rights and does not require them to enter their password. The vulnerability exists even with the LXD snap package.
This issue is not about container break-outs and requires an attacker to already have local access to the system and be a member of the `lxd` user group.
LXD is a root process that carries out actions for anyone with write access to the LXD UNIX socket. It often does not attempt to match privileges of the calling user. There are multiple methods to exploit this. One of them is to use the LXD API to mount the host's root filesystem into a container. This gives a low-privilege user root access to the host filesystem. This is demonstrated in the exploit attached.
To use the attached exploit, first launch an LXC container using LXD. Then, run `lxd_root.sh <container name>` as a member of the `lxd` user group.
There are other, slightly more in-depth, exploitation methods as well. An example would be to create an LXD proxy device that maps a UNIX socket on the host OS into the container. This mapping will be done using a root process, so that a low-privilege user can simply use the `lxc` command to enter that container and communicate with the socket using root's peer credentials. Using this strategy, one could obtain root-level command execution by speaking to systemd's private socket, for example, linking a new malicious service and starting it. I've built a very rough proof of concept to confirm this works as well, but it is not quite ready to share.
The LXD package maintainers are aware of this and have deemed it not a security issue. Some examples of existing public discussions are:
- https:/
- https:/
I'm raising this issue on the Ubuntu bug tracker as it is a Canonical-sponsored project and Ubuntu users are told to add users to this account without warning them that it breaks Ubuntu's intended security model. Some examples are here:
- https:/
- https:/
And of course the official LXD getting started guide here:
- https:/
The links above states `If the "lxd" group is missing on your system, create it, then restart the LXD daemon. You can then add trusted users to it. Anyone added to this group will have full control over LXD.` When, in fact, it should state that anyone added to this group will have full control over the host OS, bypassing intended privileged access checks like a sudo password requirement.
I think it would be worthwhile making this extremely clear in all official Ubuntu documentation and blogs, as well.
From my perspective, this looks like a typical root exploit worthy of a CVE and a customer notification. I'm submitting this as a private bug so that you can review before making public. As the vulnerability has already been discussed on GitHub, the issue of course is already in the public domain.
Thanks for reading!
Changed in lxd (Ubuntu): | |
status: | New → Confirmed |
Just a note, others who have found and are providing details on how to exploit this: /reboare. github. io/lxd/ lxd-escape. html /calap. co/blog/ hackistanbul- ctf-brazil- writeup- -2018-09- 10.html
- https:/
- https:/