Overlayfs in user namespace leaks directory content of inaccessible directories
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Medium
|
Tyler Hicks | ||
Bionic |
Fix Released
|
Medium
|
Tyler Hicks | ||
Cosmic |
Fix Released
|
Medium
|
Tyler Hicks | ||
Disco |
Fix Released
|
Medium
|
Tyler Hicks |
Bug Description
Summary: With a combination of overlayfs and user namespaces, regular users can see the content of directories that would otherwise be inaccessible to them because of directory permissions (e.g., all users can see content of "/root").
Details: For the exploit it is necessary to create user and mount namespaces and mount an overlayfs inside it. Ubuntu allows this for regular users. The lower dir of the overlay would be "/", and the upper dir an attacker-controlled temporary directory. If the attacker wants to see the content of "/root", they would create a directory "root" in the upper dir of the overlay. Overlays seems to get confused about the permissions, and instead of applying the restrictive permissions of "root" from the lower dir, it applies more relaxed restrictions of "root" from the upper dir, granting the attacker the possibility to list the directory contents of "/root".
To reproduce, simply run the attached script as regular user. It will show the content of "/root", on my system the output is this:
```
/bin/ls: cannot access '/root/.cache': Permission denied
/bin/ls: cannot access '/root/.bashrc': Permission denied
/bin/ls: cannot access '/root/snap': Permission denied
/bin/ls: cannot access '/root/.gnupg': Permission denied
/bin/ls: cannot access '/root/.aptitude': Permission denied
/bin/ls: cannot access '/root/
/bin/ls: cannot access '/root/.profile': Permission denied
/bin/ls: cannot access '/root/.hplip': Permission denied
total 8
drwxr-xr-x 1 nobody nogroup 4096 Sep 20 09:02 .
drwxr-xr-x 1 nobody nogroup 4096 Sep 20 09:02 ..
d????????? ? ? ? ? ? .aptitude
-????????? ? ? ? ? ? .bash_history
-????????? ? ? ? ? ? .bashrc
d????????? ? ? ? ? ? .cache
d????????? ? ? ? ? ? .gnupg
d????????? ? ? ? ? ? .hplip
-????????? ? ? ? ? ? .profile
d????????? ? ? ? ? ? snap
```
The script also has some comments that explain the necessary steps in more details.
I tested on Ubuntu 18.04 with Linux 4.15.0-34-generic, but the bug probably affects all Ubuntu versions of the last years. Other distributions and the vanilla kernel should not be affected because AFAIK only Ubuntu allows mounting of overlayfs inside user namespaces. But of course it would be good to apply a potential fix upstream.
So far I did not succeed in doing more than leaking the directory content, but of course that is no guarantee that it is not possible to do worse things.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-
ProcVersionSign
Uname: Linux 4.15.0-34-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.3
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
/dev/snd/
CurrentDesktop: Unity:Unity7:ubuntu
Date: Thu Sep 20 08:56:01 2018
HibernationDevice: RESUME=
InstallationDate: Installed on 2016-12-12 (646 days ago)
InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
MachineType: LENOVO 20FXS1B700
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=
RelatedPackageV
linux-
linux-
linux-firmware 1.173.1
SourcePackage: linux
UpgradeStatus: Upgraded to bionic on 2018-09-04 (15 days ago)
dmi.bios.date: 09/26/2016
dmi.bios.vendor: LENOVO
dmi.bios.version: R07ET71W (2.11 )
dmi.board.
dmi.board.name: 20FXS1B700
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.
dmi.modalias: dmi:bvnLENOVO:
dmi.product.family: ThinkPad T460p
dmi.product.name: 20FXS1B700
dmi.product.
dmi.sys.vendor: LENOVO
CVE References
Changed in linux (Ubuntu): | |
assignee: | nobody → Tyler Hicks (tyhicks) |
information type: | Private Security → Public Security |
tags: | added: patch |
Changed in linux (Ubuntu Cosmic): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Bionic): | |
status: | In Progress → Fix Committed |
Thanks for the bug report and the proof of concept! I've been able to reproduce the issue on 4.15.0- 36.39-generic.
I'll start looking into the proper fix now.