Overlayfs in user namespace leaks directory content of inaccessible directories
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| linux (Ubuntu) |
Medium
|
Tyler Hicks | ||
| 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/
/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
Philipp Wendler (philw85) wrote : | #1 |
Changed in linux (Ubuntu): | |
assignee: | nobody → Tyler Hicks (tyhicks) |
Tyler Hicks (tyhicks) wrote : | #3 |
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 : | #4 |
This flaw is related to CVE-2015-1328:
https:/
It was fixed by this patch:
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:/
Here's the fix for that issue:
https:/
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 c0ca3d70e8d3cf8
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 : | #5 |
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 : | #6 |
This issue is CVE-2018-6559.
information type: | Private Security → Public Security |
Tyler Hicks (tyhicks) wrote : | #7 |
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 |
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 : | #8 |
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-
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:/
tags: | added: verification-needed-cosmic |
Brad Figg (brad-figg) wrote : | #9 |
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-
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:/
tags: | added: verification-needed-bionic |
Philipp Wendler (philw85) wrote : | #10 |
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.
Tyler Hicks (tyhicks) wrote : Re: [Bug 1793458] Re: Overlayfs in user namespace leaks directory content of inaccessible directories | #11 |
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 : | #12 |
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 |
Tyler Hicks (tyhicks) wrote : | #13 |
I've verified the fix in 4.18.0-
tags: |
added: verification-done-cosmic removed: verification-needed-cosmic |
Launchpad Janitor (janitor) wrote : | #14 |
This bug was fixed in the package linux - 4.18.0-12.13
---------------
linux (4.18.0-12.13) cosmic; urgency=medium
* linux: 4.18.0-12.13 -proposed tracker (LP: #1802743)
* [FEAT] Guest-dedicated Crypto Adapters (LP: #1787405)
- s390/zcrypt: Add ZAPQ inline function.
- s390/zcrypt: Review inline assembler constraints.
- s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.
- s390/zcrypt: fix ap_instructions
- KVM: s390: vsie: simulate VCPU SIE entry/exit
- KVM: s390: introduce and use KVM_REQ_
- KVM: s390: refactor crypto initialization
- s390: vfio-ap: base implementation of VFIO AP device driver
- s390: vfio-ap: register matrix device with VFIO mdev framework
- s390: vfio-ap: sysfs interfaces to configure adapters
- s390: vfio-ap: sysfs interfaces to configure domains
- s390: vfio-ap: sysfs interfaces to configure control domains
- s390: vfio-ap: sysfs interface to view matrix mdev matrix
- KVM: s390: interface to clear CRYCB masks
- s390: vfio-ap: implement mediated device open callback
- s390: vfio-ap: implement VFIO_DEVICE_
- s390: vfio-ap: zeroize the AP queues
- s390: vfio-ap: implement VFIO_DEVICE_RESET ioctl
- KVM: s390: Clear Crypto Control Block when using vSIE
- KVM: s390: vsie: Do the CRYCB validation first
- KVM: s390: vsie: Make use of CRYCB FORMAT2 clear
- KVM: s390: vsie: Allow CRYCB FORMAT-2
- KVM: s390: vsie: allow CRYCB FORMAT-1
- KVM: s390: vsie: allow CRYCB FORMAT-0
- KVM: s390: vsie: allow guest FORMAT-0 CRYCB on host FORMAT-1
- KVM: s390: vsie: allow guest FORMAT-1 CRYCB on host FORMAT-2
- KVM: s390: vsie: allow guest FORMAT-0 CRYCB on host FORMAT-2
- KVM: s390: device attrs to enable/disable AP interpretation
- KVM: s390: CPU model support for AP virtualization
- s390: doc: detailed specifications for AP virtualization
- KVM: s390: fix locking for crypto setting error path
- KVM: s390: Tracing APCB changes
- s390: vfio-ap: setup APCB mask using KVM dedicated function
- [Config:] Enable CONFIG_
* Bypass of mount visibility through userns + mount propagation (LP: #1789161)
- mount: Retest MNT_LOCKED in do_umount
- mount: Don't allow copying MNT_UNBINDABLE|
* CVE-2018-18955: nested user namespaces with more than five extents
incorrectly grant privileges over inode (LP: #1801924) // CVE-2018-18955
- userns: also map extents in the reverse map to kernel IDs
* kdump fail due to an IRQ storm (LP: #1797990)
- SAUCE: x86/PCI: Export find_cap() to be used in early PCI code
- SAUCE: x86/quirks: Add parameter to clear MSIs early on boot
- SAUCE: x86/quirks: Scan all busses for early PCI quirks
* crash in ENA driver on removing an interface (LP: #1802341)
- SAUCE: net: ena: fix crash during ena_remove()
* Ubuntu 18.04.1 - [s390x] Kernel panic while stressing network bonding
(LP: #1797367)
- s390/qeth: reduce hard-coded access to ccw channels
- s390/qeth: sanitize strings in debug messages
* Add checksum offload and T...
Changed in linux (Ubuntu Cosmic): | |
status: | Fix Committed → Fix Released |
Launchpad Janitor (janitor) wrote : | #15 |
This bug was fixed in the package linux - 4.15.0-42.45
---------------
linux (4.15.0-42.45) bionic; urgency=medium
* linux: 4.15.0-42.45 -proposed tracker (LP: #1803592)
* [FEAT] Guest-dedicated Crypto Adapters (LP: #1787405)
- KVM: s390: reset crypto attributes for all vcpus
- KVM: s390: vsie: simulate VCPU SIE entry/exit
- KVM: s390: introduce and use KVM_REQ_
- KVM: s390: refactor crypto initialization
- s390: vfio-ap: base implementation of VFIO AP device driver
- s390: vfio-ap: register matrix device with VFIO mdev framework
- s390: vfio-ap: sysfs interfaces to configure adapters
- s390: vfio-ap: sysfs interfaces to configure domains
- s390: vfio-ap: sysfs interfaces to configure control domains
- s390: vfio-ap: sysfs interface to view matrix mdev matrix
- KVM: s390: interface to clear CRYCB masks
- s390: vfio-ap: implement mediated device open callback
- s390: vfio-ap: implement VFIO_DEVICE_
- s390: vfio-ap: zeroize the AP queues
- s390: vfio-ap: implement VFIO_DEVICE_RESET ioctl
- KVM: s390: Clear Crypto Control Block when using vSIE
- KVM: s390: vsie: Do the CRYCB validation first
- KVM: s390: vsie: Make use of CRYCB FORMAT2 clear
- KVM: s390: vsie: Allow CRYCB FORMAT-2
- KVM: s390: vsie: allow CRYCB FORMAT-1
- KVM: s390: vsie: allow CRYCB FORMAT-0
- KVM: s390: vsie: allow guest FORMAT-0 CRYCB on host FORMAT-1
- KVM: s390: vsie: allow guest FORMAT-1 CRYCB on host FORMAT-2
- KVM: s390: vsie: allow guest FORMAT-0 CRYCB on host FORMAT-2
- KVM: s390: device attrs to enable/disable AP interpretation
- KVM: s390: CPU model support for AP virtualization
- s390: doc: detailed specifications for AP virtualization
- KVM: s390: fix locking for crypto setting error path
- KVM: s390: Tracing APCB changes
- s390: vfio-ap: setup APCB mask using KVM dedicated function
- s390/zcrypt: Add ZAPQ inline function.
- s390/zcrypt: Review inline assembler constraints.
- s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.
- s390/zcrypt: fix ap_instructions
- s390/zcrypt: remove VLA usage from the AP bus
- s390/zcrypt: Remove deprecated ioctls.
- s390/zcrypt: Remove deprecated zcrypt proc interface.
- s390/zcrypt: Support up to 256 crypto adapters.
- [Config:] Enable CONFIG_
* Bypass of mount visibility through userns + mount propagation (LP: #1789161)
- mount: Retest MNT_LOCKED in do_umount
- mount: Don't allow copying MNT_UNBINDABLE|
* CVE-2018-18955: nested user namespaces with more than five extents
incorrectly grant privileges over inode (LP: #1801924) // CVE-2018-18955
- userns: also map extents in the reverse map to kernel IDs
* kdump fail due to an IRQ storm (LP: #1797990)
- SAUCE: x86/PCI: Export find_cap() to be used in early PCI code
- SAUCE: x86/quirks: Add parameter to clear MSIs early on boot
- SAUCE: x86/quirks: Scan all busses for early PCI quirks
-- Thadeu Lima de Souza Cascardo <email address hidden> Thu, 15 Nov 2018 17:01:46 ...
Changed in linux (Ubuntu Bionic): | |
status: | Fix Committed → Fix Released |
Launchpad Janitor (janitor) wrote : | #16 |
This bug was fixed in the package linux - 4.19.0-12.13
---------------
linux (4.19.0-12.13) disco; urgency=medium
* linux: 4.19.0-12.13 -proposed tracker (LP: #1813664)
* kernel oops in bcache module (LP: #1793901)
- SAUCE: bcache: never writeback a discard operation
* Disco update: 4.19.18 upstream stable release (LP: #1813611)
- ipv6: Consider sk_bound_dev_if when binding a socket to a v4 mapped address
- mlxsw: spectrum: Disable lag port TX before removing it
- mlxsw: spectrum_switchdev: Set PVID correctly during VLAN deletion
- net: dsa: mv88x6xxx: mv88e6390 errata
- net, skbuff: do not prefer skb allocation fails early
- qmi_wwan: add MTU default to qmap network interface
- ipv6: Take rcu_read_lock in __inet6_bind for mapped addresses
- net: clear skb->tstamp in bridge forwarding path
- netfilter: ipset: Allow matching on destination MAC address for mac and
ipmac sets
- gpio: pl061: Move irq_chip definition inside struct pl061
- drm/amd/display: Guard against null stream_state in set_crc_source
- drm/amdkfd: fix interrupt spin lock
- ixgbe: allow IPsec Tx offload in VEPA mode
- platform/x86: asus-wmi: Tell the EC the OS will handle the display off
hotkey
- e1000e: allow non-monotonic SYSTIM readings
- usb: typec: tcpm: Do not disconnect link for self powered devices
- selftests/bpf: enable (uncomment) all tests in test_libbpf.sh
- of: overlay: add missing of_node_put() after add new node to changeset
- writeback: don't decrement wb->refcnt if !wb->bdi
- serial: set suppress_bind_attrs flag only if builtin
- bpf: Allow narrow loads with offset > 0
- ALSA: oxfw: add support for APOGEE duet FireWire
- x86/mce: Fix -Wmissing-
- MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur
- crypto: ecc - regularize scalar for scalar multiplication
- arm64: perf: set suppress_bind_attrs flag to true
- drm/atomic-helper: Complete fake_commit-
- clk: meson: meson8b: fix incorrect divider mapping in cpu_scale_table
- samples: bpf: fix: error handling regarding kprobe_events
- usb: gadget: udc: renesas_usb3: add a safety connection way for
forced_
- fpga: altera-cvp: fix probing for multiple FPGAs on the bus
- selinux: always allow mounting submounts
- ASoC: pcm3168a: Don't disable pcm3168a when CONFIG_PM defined
- scsi: qedi: Check for session online before getting iSCSI TLV data.
- drm/amdgpu: Reorder uvd ring init before uvd resume
- rxe: IB_WR_REG_MR does not capture MR's iova field
- efi/libstub: Disable some warnings for x86{,_64}
- jffs2: Fix use of uninitialized delayed_work, lockdep breakage
- clk: imx: make mux parent strings const
- pstore/ram: Do not treat empty buffers as valid
- media: uvcvideo: Refactor teardown of uvc on USB disconnect
- powerpc/xmon: Fix invocation inside lock region
- powerpc/
- media: firewire: Fix app_info parameter type in avc_ca{,_app}_info
- ASoC: use dma_ops of parent device for acp_audio_dma
- media: ve...
Changed in linux (Ubuntu Disco): | |
status: | In Progress → Fix Released |
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.