That vulnerability only applies to HVM guests. No doubt there are other reasons to have rebooted since 2013, but if one of Rackspace's servers only has paravirtualized guests (do they use HVM at all? I don't know), they can get by without patching it.
Did you see how many vulnerabilities 659 days covers? I mean, if that one doesn't apply, just go back a bit. How about this one from June 2014:
memory pages that were in use by the hypervisor and are eligible to be allocated to guests weren't being properly cleaned. Such exposure of information would happen through
memory pages freshly allocated to or by the guest. ... it is possible for an attacker to obtain modest amounts of in-flight and in-use data, which might contain passwords or cryptographic keys.
Is that a guest or a host? If it's a guest, there shouldn't be a need for reboot, only suspend/resume... (note that a reboot can be a good idea from time to time, just to make sure the current configuration (eg: post kernel upgrades, before reboot) -- actually boots).
If the kernel you are running on is vulnerable, it can be attacked and the attacker can circumvent any container isolation.
If the hypervisor (Xen!) running underneath your container-Linux is vulnerable, the attacker can get access to your virtualized OS and circumvent any container isolation.
There are a lot of vulnerabilities which don't affect them though -- either because the vulnerabilities are in specific features which EC2 doesn't use, or because Amazon is very conservative about which versions of Xen it uses and most vulnerabilities are in relatively new code.
I certainly hope Amazon will respond to these publicly, but I won't be very surprised if the response is "doesn't affect us".
Xen's hypervisor would seem to be a great place to implement live patching like KSplice/kGraft/Kpatch does for the Linux kernel. Presumably that stuff still works on KVM host machines with live guests.
It could be either that (live patching) or live migration: do a live migration of all instances on this host to an already patched host, reboot the host, repeat for the next host.
> While all instance types need to be updated, we have developed the capability to live-update instances running on newer hardware. The vast majority of the EC2 fleet will be live-updated, but a portion of instances (less than 10% of customer EC2 instances) running on older hardware will require a reboot to complete the update process.
"We’ve received a Xen Security Advisory that requires us to update a portion of our Amazon EC2 fleet. Fewer than 10% of EC2 customer instances will need to be rebooted. We’ve started notifying affected customers when their reboots will take place. These updates must be completed by March 10, 2015 before the underlying issues we are addressing are made public. Following security best practices, the details behind these issues will be withheld until they are made public on March 10."
Because responsible adults have demonstrated their ability to follow a coordinated disclosure policy which lets them improve their own security without harming anyone else's.
From what I understand, the bar to get on the pre-disclosure list is not high. If you are a legitimate company serving the public you will likely qualify.
One working week between notification arriving at security@xenproject and the issue of our own advisory to our predisclosure list. We will use this time to gather information and prepare our advisory, including required patches.
Two working weeks between issue of our advisory to our predisclosure list and publication.
When a discoverer reports a problem to us and requests longer delays than we would consider ideal, we will honour such a request if reasonable. If a discoverer wants an accelerated disclosure compared to what we would prefer, we naturally do not have the power to insist that a discoverer waits for us to be ready and will honour the date specified by the discoverer.
Naturally, if a vulnerability is being exploited in the wild we will make immediately public release of the advisory and patch(es) and expect others to do likewise.
This is an extraordinarily aggressive (in a good way) and transparent process. Big commercial vendors routinely sit on vulnerabilities for months.
First kernel with certain security guarantees formally proven; now open source. It can be used as a hypervisor which seems like its most obvious first use case. At least until there is enough middle-ware to build full systems directly with it.
It is indeed awesome, but from a practical perspective it doesn't even compare with Xen.
Hardware support is up to you. I think you can boot it on x86, but that's just the microkernel -- you have to add all the hardware support. I don't think seL4 is meant to run on servers either.
49 comments
[ 2.9 ms ] story [ 93.1 ms ] threadSee https://community.rackspace.com/general/f/53/t/4978
04:49:58 up 659 days
your server is vulnerable to a number of Xen security vulnerabilities: http://xenbits.xen.org/xsa/
Including this one from Oct 1, 2014 that allows guests to read up to 3KB of memory from the hypervisor or other guests:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7188
http://threatpost.com/serious-hypervisor-bug-fix-causes-unex...
memory pages that were in use by the hypervisor and are eligible to be allocated to guests weren't being properly cleaned. Such exposure of information would happen through memory pages freshly allocated to or by the guest. ... it is possible for an attacker to obtain modest amounts of in-flight and in-use data, which might contain passwords or cryptographic keys.
http://xenbits.xen.org/xsa/advisory-100.html
https://medium.com/@fun_cuddles/docker-breakout-exploit-anal...
If the hypervisor (Xen!) running underneath your container-Linux is vulnerable, the attacker can get access to your virtualized OS and circumvent any container isolation.
I certainly hope Amazon will respond to these publicly, but I won't be very surprised if the response is "doesn't affect us".
> While all instance types need to be updated, we have developed the capability to live-update instances running on newer hardware. The vast majority of the EC2 fleet will be live-updated, but a portion of instances (less than 10% of customer EC2 instances) running on older hardware will require a reboot to complete the update process.
"We’ve received a Xen Security Advisory that requires us to update a portion of our Amazon EC2 fleet. Fewer than 10% of EC2 customer instances will need to be rebooted. We’ve started notifying affected customers when their reboots will take place. These updates must be completed by March 10, 2015 before the underlying issues we are addressing are made public. Following security best practices, the details behind these issues will be withheld until they are made public on March 10."
http://www.xenproject.org/security-policy.html
Two working weeks between issue of our advisory to our predisclosure list and publication.
When a discoverer reports a problem to us and requests longer delays than we would consider ideal, we will honour such a request if reasonable. If a discoverer wants an accelerated disclosure compared to what we would prefer, we naturally do not have the power to insist that a discoverer waits for us to be ready and will honour the date specified by the discoverer.
Naturally, if a vulnerability is being exploited in the wild we will make immediately public release of the advisory and patch(es) and expect others to do likewise.
This is an extraordinarily aggressive (in a good way) and transparent process. Big commercial vendors routinely sit on vulnerabilities for months.
First kernel with certain security guarantees formally proven; now open source. It can be used as a hypervisor which seems like its most obvious first use case. At least until there is enough middle-ware to build full systems directly with it.
Hardware support is up to you. I think you can boot it on x86, but that's just the microkernel -- you have to add all the hardware support. I don't think seL4 is meant to run on servers either.