OpenVZ kernel team discovered security issue that allows privileged user inside container to get access to files on host. All kind of containers affected: simfs, ploop and vzfs. Affected all kernels since 2.6.32-042stab105.x
Note: RHEL5-based kernels 2.6.18, Red Hat and mainline kernels are not affected.
CVE-2015-0239 kvm: insufficient sysenter emulation when invoked from 16-bit code
CVE-2015-3339 kernel: race condition between chown() and execve()
Note: RHEL5-based kernels 2.6.18 are not affected.
It is quite critical to install latest OpenVZ kernel to protect your systems. Please reboot your nodes into fixed kernels or install live patches from Kernel Care.
Yesterday a guy with his name written in Cyrillic letters ("Марк Коренберг") and a @gmail.com email address posted a kernel exploit to the Linux kernel mailing list (aka LKML). This morning one brave guy from our team tried to run it on his desktop -- and had to reboot it after a few minutes of total system unresponsiveness.
The bad news are the exploit is pretty serious and causes Denial of Service. It looks like most kernels are indeed vulnerable.
The good news is OpenVZ is not vulnerable. Why? Because of user beancounters.
Of course, if you set all beancounters to unlimited, exploit will work. So don't do that, unless your CT is completely trusted. Those limits are there for a reason, you know.
Quite frequently, people ask me if OpenVZ is secure enough. They are thinking that because in OpenVZ everything is running under one single kernel (as opposed to, say Xen or VMware, where each partition runs each own kernel), this single kernel is a single point of failure (SPOF).
The answer is: yes, OpenVZ stable kernel is secure enough to be used for production workloads and in hostile environments. Why? The long answer involves a comparison of different virtualization techniques and their SPOFs, a description of OpenVZ architecture, the "denied by default" principle, the fact that its practically proven on a thousands of servers, etc. The short answer is: because we care.
Security is quite a complex field. It's not enough to write secure code once, or secure your system once. In the real world, security comes from constant care. In other words, it’s not enough for a sys admin who is using a good, secure operating system, but doesn't care daily about security.
The Linux kernel is quite secure. Still, new problems are found and resolved from time to time, by those people who care. Most of them are security experts (like Solar Designer), others just work on Linux.
A few days ago, Red Hat released a new update to RHEL4 kernel (RHSA-2007-0014). Let me quote: Red Hat would like to thank Dmitriy Monakhov and Konstantin Khorenko for reporting issues fixed in this erratum.
Both Dmitriy and Konstantin are working in our Virtuozzo/OpenVZ team. Dmitriy works in the Quality Assurance department (which I wrote about before), making sure our kernels are rock-solid (by trying to break it badly, that is). Konstantin works in our kernel support team, mostly fixing the causes of kernel oopses. Besides that, as you see, they both care for security (as well as everybody else in our team). They find bugs (including security bugs), they report and fix those, they send the results to major distribution vendors (and it's not the first time Red Hat has acknowledged our developers), as well as mainstream Linux (again, I wrote about it as well before).
And this is how Linux wins: with all the parties contributing to everybody's benefit.
I tried it and was able to migrate a CentOS 7 container... but the Fedora 22 one seems to be stuck in the "started" phase. It creates a /vz/private/{ctid} dir on the destination host (with the same…
The fall semester is just around the corner... so it is impossible for me to break away for a trip to Seattle. I hope one or more of you guys can blog so I can attend vicariously.
Comments
Do you still stand by your opinions above now in 2016?…