OpenVZ simfs container filesystem breakout

An attacker is able to access files outside of his container.

Function open_by_handle_at() enables process to access files on a mounted filesystem
using file_handle structure. This structure is using inode numbers to differentiate files.
Calling this function requires CAP_DAC_READ_SEARCH capability and superuser inside
a container by default has this capability.

This enables an attacker to bypass simfs restrictions and access all files on an underlying
filesystem including other VE’s residing on the same filesystem.

This is the same issue as the one affecting docker which was discovered recently by by Sebastian Krahmer.
He wrote about it on this list http://www.openwall.com/lists/oss-security/2014/06/18/4 .

This vulnerability is identified by CVE-2014-3519 .

For further technical information please refer to Sebastian Krahmers post and POC
(http://stealth.openwall.net/xSports/shocker.c).

His POC code works with openvz with cosmetic modifications so we have to consider that public exploit is readily
available.

Affected versions:
all RHEL6 based openvz kernels older then 042stab090.5 released today and using simfs (VE_LAYOUT=simfs).

Unaffected versions:
RHEL5 based openvz lack open_by_handle_at(2) function
RHEL6 based openvz using exclusivelly ploop or parallels commercial vzfs

Newest vzctl packages defaults to unaffected ploop layout. Parallels comercial vzfs is also unaffected.

Disabling CAP_DAC_READ_SEARCH inside the containers can be used as an mitigation technique
if kernel upgrade is not possible.

# vzctl vied --save --capability DAC_READ_SEARCH:off --setmode restart
(It will immediately restart the VE)

I think it won’t break any typical software running inside the CT but Your milage may vary.


References:
http://kb.parallels.com/en/122142
https://openvz.org/Download/kernel/rhel6/042stab090.5
http://www.openwall.com/lists/oss-security/2014/06/18/4

--
Authored by
Michał Grzędzicki
e-mail: mg () iq pl
IQ PL Sp. z o.o.