Fix for CVE-2014-3153 in OpenVZ

jmginer

Hello, we have applied the upgrade 042stab090.3,

but the kernel showed in the containers is not fixed.

We need do a stop/start on all containers to fix the bug?

HOST NODE is fixed (after reboot)

[root@mad1-ovz2 ~]# uname -a
Linux mad1-ovz2.ginernet.com 2.6.32-042stab090.3 #1 SMP Fri Jun 6 09:35:21 MSK 2014 x86_64 x86_64 x86_64 GNU/Linux
[root@mad1-ovz2 ~]#

Containers are still with old kernel...

[root@mad1-ovz2 ~]# vzctl enter 2267
entered into CT 2267
root@server [/]# uname -a
Linux server.xxxxx.com 2.6.32-042stab085.20 #1 SMP Fri Jun 6 09:35:21 MSK 2014 x86_64 x86_64 x86_64 GNU/Linux
root@server [/]# exit
logout
exited from CT 2267
[root@mad1-ovz2 ~]#

Thanks!

DigitalDuke

I had this issue, the way I fixed it was to restart the actual containers individually.

petris

When containers are suspended rather than shutdown, they keep the old kernel version number and uptime. You're fine though as it's only cosmetic.

jmginer

@petris said:
When containers are suspended rather than shutdown, they keep the old kernel version number and uptime. You're fine though as it's only cosmetic.

Are you saying that I dont need to reboot the containers?

petris

@jmginer said:
Are you saying that I dont need to reboot the containers?

You do not need to reboot your containers. Remember OpenVZ uses the host kernel. I presume that they keep the old kernel version, etc., when the container is suspended to keep things inside the container from going bonkers.

Restarting doesn't hurt though if it will make you sleep better at night.

jmginer

@DigitalDuke : Script to restart all containers...

#! /bin/bash

ls -r1 /vz/private > listvz.txt;

cat listvz.txt | while read line; do

echo STOPPING ${line}
vzctl stop ${line}
echo STARTING ${line}
vzctl start ${line}
sleep 10;

done

Nick_A

This is not going to be a fun day.

Patrick

Use http://kernelcare.com if you don't want to go around rebooting.

Neoon

Debian 3.2.54-2 i686 GNU/Linux is not fixed? but didnt got an update.

alexvolk

@INIZ said:
Use http://kernelcare.com if you don't want to go around rebooting.

So from what I understand it's the same guys who is behing CloudLinux ?

jh

alexvolk said: So from what I understand it's the same guys who is behing CloudLinux ?

Yes

AnthonySmith

@INIZ said:
Use http://kernelcare.com if you don't want to go around rebooting.

Damn I wish I knew about that sooner any issues with it to date?

Patrick

@AnthonySmith said:
Damn I wish I knew about that sooner any issues with it to date?

None, I've been running it on one node for a few weeks. Put it on all last night when OpenVZ tweeted about the vuln.

It has similar functionality to KSplice if not the same. You can also see the patches here:
http://patches.kernelcare.com

Ishaq

Is it only me that finds it odd that a vulnerability comes out shortly after KernelCare gets released?

Coincidence? perhaps.

rsk

Ishaq said: Is it only me that finds it odd that a vulnerability comes out shortly after KernelCare gets released?

I thought it was quite old? no?

Especially the dates on their website indicate May (in their faq)?

jar

@Zen said:
FTFY

for vz in $(vzlist -H -o ctid); do vzctl stop $vz && vzctl start $vz; done

One liners win

c0y

jarland said: for vz in $(vzlist -H -o ctid); do vzctl stop $vz && vzctl start $vz; done

One liners win

You beat me to it :-)

Also, by using && after stop you won't boot containers supposed to be shutdown

linuxthefish

Nothing showing in vzlist after yum update, and getting "container file does not exist" with vzctl start

linuxthefish

@Jack said:
What are you running?

CentOS 6 64bit, no control panel or anything. Booting into 2.6.32-042stab088.4 doesn't work either

[root@fr1 ~]# vzctl create 10 --ostemplate debian-7.0-x86
vzquota : (error) Quota on syscall for id 10: File exists
vzquota : (error)       Native quota is already running for this partition.
vzquota on failed [3]
Creating container private area (debian-7.0-x86)
vzquota : (error) Quota is not running for id 10
vzquota : (error) Quota on syscall for id 10: File exists
vzquota : (error)       Native quota is already running for this partition.
vzquota on failed [3]
Destroying container private area: /vz/private/10
Creation of container private area failed

petris

@linuxthefish said:

https://openvz.org/User_Guide/Operations_on_Containers

The OpenVZ software reserves the IDs ranging from 0 to 100. Though OpenVZ uses only ID 0, future versions might use additional Container IDs for internal needs. To facilitate upgrading, please do not create Containers with IDs below 101.

I'm not sure if they started using other container ids however this could be part of your problem.

linuxthefish

@petris said:
I'm not sure if they started using other container ids however this could be part of your problem.

Missed the extra 1 out on the end, although it's the same issue with any ID's.

KuJoe

Have you tried turning the quota off?

vzquota off 101

linuxthefish

@KuJoe said:
Have you tried turning the quota off?

vzquota off 101

Yeah I've tried that, quota is not running, and turning it on gives "Native quota is already running for this partition."

petris

@linuxthefish said:
Yeah I've tried that, quota is not running, and turning it on gives "Native quota is already running for this partition."

This may sound like a silly question, however is your /vz partition mounted?

linuxthefish

@petris said:

I can browse /vz, is that good enough?

rsk

linuxthefish said: I can browse /vz, is that good enough?

Then it is mounted.

GVH_Rakesh

can we be affected by this on us? I must contact the management

Patrick

@GVH_Rakesh said:
can we be affected by this on us? I must contact the management

Saving before its edited.

Rob92

lol.

Neoon

@GVH_Rakesh said:
can we be affected by this on us? I must contact the management

Wait until someone exploit your nodes, you will notice.

jnguyen

@GVH_Rakesh has been banned for pretending to be a member of staff.