Overlayfs in user namespace leaks directory content of inaccessible directories

Bug #1793458 reported by Philipp Wendler on 2018-09-20
260
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Status tracked in Disco
Bionic
Medium
Tyler Hicks
Cosmic
Medium
Tyler Hicks
Disco
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/.bash_history': Permission denied
/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-4.15.0-34-generic 4.15.0-34.37
ProcVersionSignature: Ubuntu 4.15.0-34.37-generic 4.15.18
Uname: Linux 4.15.0-34-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: wendler 3414 F.... pulseaudio
 /dev/snd/controlC0: wendler 3414 F.... pulseaudio
CurrentDesktop: Unity:Unity7:ubuntu
Date: Thu Sep 20 08:56:01 2018
HibernationDevice: RESUME=UUID=f9d1a1f9-50d2-4b7c-b7e4-66dc78d38062
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=/vmlinuz-4.15.0-34-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=/dev/mapper/ubuntu--vg-swap_1 swapaccount=1
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-34-generic N/A
 linux-backports-modules-4.15.0-34-generic N/A
 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.asset.tag: Not Available
dmi.board.name: 20FXS1B700
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrR07ET71W(2.11):bd09/26/2016:svnLENOVO:pn20FXS1B700:pvrThinkPadT460p:rvnLENOVO:rn20FXS1B700:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad T460p
dmi.product.name: 20FXS1B700
dmi.product.version: ThinkPad T460p
dmi.sys.vendor: LENOVO

CVE References

Philipp Wendler (philw85) wrote :
Changed in linux (Ubuntu):
assignee: nobody → Tyler Hicks (tyhicks)
Tyler Hicks (tyhicks) wrote :

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.

Changed in linux (Ubuntu):
status: New → Confirmed
Tyler Hicks (tyhicks) wrote :

I wanted to provide a quick update. Xenial and Trusty kernels are not affected (I haven't yet identified why). I've got two possible fixes and I'm deciding which one is best.

Changed in linux (Ubuntu):
status: Confirmed → In Progress
importance: Undecided → High
Tyler Hicks (tyhicks) wrote :

This flaw is related to CVE-2015-1328:

  https://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-1328.html

It was fixed by this patch:

  https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/commit/?id=98a3740920f8f3362c1ac50598af2dc632f5051a

Ubuntu carries a patch that allows overlayfs mounting inside of an unprivileged user namespace, so we were carrying the fix mentioned above as a delta against the upstream Linux kernel since the issue didn't affect upstream overlayfs. (It is worth noting that we did share the details of CVE-2015-1328 and the fix privately with upstream overlayfs)

At some point between Ubuntu 16.04 LTS and Ubuntu 18.04 LTS, the patch was incorrectly dropped. This was most likely due to upstream changes to address CVE-2018-16597:

  https://people.canonical.com/~ubuntu-security/cve/?cve=CVE-2018-16597

Here's the fix for that issue:

  https://git.kernel.org/linus/c0ca3d70e8d3cf81e2255a217f7ca402f5ed0862

In hindsight, the issues that CVE-2015-1328 represent were actually deserving of two CVEs instead of one. The first, and most severe, issue was the copy up permission check. The second issue was the readdir information disclosure. It looks like upstream actually was affected by an issue somewhat similar to the copy up aspect of CVE-2015-1328 and fixed it with the upstream commit c0ca3d70e8d3cf81e2255a217f7ca402f5ed0862 (which is different from the Ubuntu fix for the copy up aspect of CVE-2015-1328 but provides similar protections).

The readdir aspect of the CVE-2015-1328 fix needs to be forward ported to Ubuntu 18.04 LTS and newer kernels. I've done that work, created an Ubuntu kernel regression test so that this doesn't happen again, and now I'm consulting with the Ubuntu Security team as to whether or not a new CVE is needed.

Tyler Hicks (tyhicks) wrote :

Here's the forwarded ported and modified fix (against the Ubuntu 18.10 kernel) for the readdir issue described in the bug description.

Tyler Hicks (tyhicks) wrote :

This issue is CVE-2018-6559.

Tyler Hicks (tyhicks) on 2018-10-19
information type: Private Security → Public Security
Tyler Hicks (tyhicks) wrote :
Changed in linux (Ubuntu Bionic):
status: New → In Progress
importance: Undecided → Medium
Changed in linux (Ubuntu Cosmic):
importance: High → Medium
Changed in linux (Ubuntu Bionic):
assignee: nobody → Tyler Hicks (tyhicks)
tags: added: patch
Stefan Bader (smb) on 2018-11-08
Changed in linux (Ubuntu Cosmic):
status: In Progress → Fix Committed
Changed in linux (Ubuntu Bionic):
status: In Progress → Fix Committed
Brad Figg (brad-figg) wrote :

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-cosmic' to 'verification-done-cosmic'. If the problem still exists, change the tag 'verification-needed-cosmic' to 'verification-failed-cosmic'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-cosmic
Brad Figg (brad-figg) wrote :

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-bionic
Philipp Wendler (philw85) wrote :

I find the demand to test the fix within 5 days, combined with the threat of dropping the patch otherwise, unreasonable.

In my original report of this security problem I have already provided a script that allows to reproduce the problem and check if it still exists.

Requiring an answer within 5 days is too short, after all people can be on holiday or just busy for other reasons.

And even if I as the original submitter wouldn't respond at all, this is a real security problem in Ubuntu that was already confirmed. Are you really going to drop the patch and let CVE-2018-6559 stay unfixed forever?

Maybe I will find the time to test it on Bionic, but I will certainly not install a different version of Ubuntu than the one I am currently running.

I hope that this is all just a misunderstanding and the message does not apply to security problems. In this case please consider changing the message or improving the process such that this confusion will be avoided for future reports.

On 2018-11-19 18:14:43, Philipp Wendler wrote:
> I hope that this is all just a misunderstanding and the message does not
> apply to security problems. In this case please consider changing the
> message or improving the process such that this confusion will be
> avoided for future reports.

Hi Philipp - I'm sorry about the confusion that comment caused. The
comment was created by an automated script that the kernel team uses to
help with the stable release update process. Security fixes do receive
an exception with this policy.

The common case is that we track security fixes with CVE IDs instead of
Launchpad bug reports. In this case, we do have a bug report for this
security issue so it gets lumped in with all of the other non-security
fixes that are subject to this policy.

Philipp Wendler (philw85) wrote :

Tyler, thanks for the clarification.

I have tested it with 4.15.0-42-generic from bionic-proposed and can confirm it is fixed.

tags: added: verification-done-bionic
removed: verification-needed-bionic
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers