Secure Dragon emergency reboot?

[MannDude]

Hello Curtis

 

This e-mail needed to be sent twice to ensure delivery because our first batch stopped halfway so we apologize if you are receiving this twice.
 


A critical vulnerability has been found in all previous version of the linux kernel and we will need to upgrade all of our servers immediately to the latest kernel version. Unfortunately this will require a reboot and this is not something we can schedule for since the vulnerability can result in total loss of data for all of our clients. We apologize for the lack of notice but because of the nature of this exploit, we cannot risk leaving our nodes out in the open.

 

Thank you for your understanding and if you have any questions please open a ticket with our Support department.



 

-The Secure Dragon Staff-
Secure Dragon LLC.


www.SecureDragon.net

Anyone know whats up?

 

[wdq]

There was a thread about this on LET. RamNode, and most likely all of the other OpenVZ hosts will be doing something similar. Here's an email I got from RamNode.

Hello,

This message is to all clients.

As many of you are aware, RedHat has recently published a critical security vulnerability. This vulnerability impacts all CentOS systems, which is what we run on our host nodes. The vulnerability does not put our nodes at risk of compromise, but OpenVZ users can cause our OpenVZ host nodes to reboot and/or kernel panic. As such, we are going to apply a kernel upgrade to all OpenVZ nodes and reboot them. We will be doing this over the course of the next few hours. Unfortunately, we cannot provide advance notice for this maintenance given the scope and risk of the vulnerability.

KVM clients running RHEL (or any derivative thereof) need to update their own kernels as soon as one becomes available from the source (CentOS, etc.). We will not be rebooting our KVM nodes at this time.

Please keep in mind that this is a RHEL/CentOS issue, and not specific to RamNode. We do everything in our power to keep your VPSs online 24/7/365, but there are cases which call for maintenance reboots like this. We cannot provide any ETAs on downtime length since that will depend on each node.

If you have any questions or concerns, please open a Support Ticket in the Client Area. Please do not respond to this email.

Thanks,

Nick
[email protected]

 

[mnpeep]

Anyone know whats up?

LET had a thread about this. Someone found a 0day in kernel.

 

[Nick]

Also received a similar one from RamNode as RedHat has recently published a critical security vulnerability and that is all I know.

 

[Zach]

Yeah it was regarding the kernel 0-day

 

[Orien]

http://www.webhostingtalk.com/showthread.php?t=1266042

 

[Jack]

The fact it took them 24 hours to do this is poor.

 

[HostUS-Alexander]

Yeah, got this from Iniz yesterday:

Hello Alexander ,

As a security precaution we have updated all our nodes kernel version to the latest version releated by OpenVZ yesterday, this update fixes a high severity 0 day exploit and as a result we will be updating all our nodes with the latest kernel and reboot the nodes to make update into effect.

The exploit in question is listed here:
https://bugzilla.redhat.com/show_bug.cgi?id=962792

Clients do not need to do anything on there end as the server kernel will also update retrospectively to your VPS as well.

Please do not submit a ticket if your VPS is down within the next few minutes / hours as we will be rebooting the nodes and should see only 15mins downtime.

Regards,
Patrick Hayward
Web Phase Limited
Iniz / Ex. StormVZ
http://iniz.com

 

[D. Strout]

I've gotten at least half a dozen of these. I don't mind the downtime, everything I have is redundant.

 

[Awmusic12635]

This is why we use Ksplice

 

[Magiobiwan]

It took I believe about 12 hours for a patched OpenVZ Kernel to be put together. And it's usually nice to have more than 15 minutes of advance notice before Emergency Maint.

 

[Nick_A]

For the record - we waited to make be sure the problem could actually be used to cause reboots/kernal panics on our OpenVZ host nodes before having to do emergency maintenance. We were going to give everyone some more notice, but it turned out to be necessary to apply a permanent fix quickly.

 

[Robert]

For the record - we waited to make be sure the problem could actually be used to cause reboots/kernal panics on our OpenVZ host nodes before having to do emergency maintenance. We were going to give everyone some more notice, but it turned out to be necessary to apply a permanent fix quickly.

I thought about it, but most people I talked to suggested upgrading the kernels right away.

 

[mikho]

The only bad thing I have to say about this is that I lost my uptime


Which is not as bad as it sounds.

 

[wlanboy]

If I look to my mailbox IPXcore was the first one writing an email. Followed by RamNode and SecureDragon.

Just wondering what my other providers are doing.

 

[KuJoe]

To be honest, RamNode's e-mail is how I found out about the OpenVZ kernel update. Prior to that, I had been waiting for the kernel update which is why there was a delay in getting it patched.

As others have said, I would have preferred to schedule this in advance but with the severity of the exploit was to high to wait any longer. We had to test the new kernel on another node before we were going to apply it to the other nodes which is why it took so long.