Five new undisclosed Xen vulnerabilities

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).

ryan-c• 11 years ago

prgmr did reboots yesterday

plq• 11 years ago

Yet linode is still silent...

kbar132• 11 years ago

realize that there's Xen HVM and Xen PV. there have been significantly more security issues in HVM than there have been in PV.

KenCochrane• 11 years ago

I got an email from linode yesterday telling me they need to do the same. Not sure if they had any public communication yet.

paulrosenzweig• 11 years ago

Linode rebooted my server in Tokyo ~16 hours ago.

runamok• 11 years ago

AWS uses xen too, right?

somanim• 11 years ago

yes part of the reason I moved away from AWS years ago. Now it doesn't even matter since I am deploying to Docker anyways.

NeutronBoy• 11 years ago

Good thing the host you run Docker on never needs to be patched or rebooted I guess?

cperciva• 11 years ago

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".

mrsteveman1• 11 years ago

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.

__bjoernd2• 11 years ago

There was this talk at last Linux Plumbers Conference, fyi: http://www.linuxplumbersconf.org/2014/ocw/sessions/2421

resc1440• 11 years ago

Amazon's security advisory seems to indicate that they have this capability for 90% of EC2 instances (leaving 10% that must be rebooted). https://aws.amazon.com/premiumsupport/maintenance-2015-03/

cesarb• 11 years ago

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.

lscotte• 11 years ago

Not really - to me, it implies that 90% of EC2 instances are not running on a vulnerable version of Xen...

pjmlp• 11 years ago

Quite a few use after free there.

namplaa• 11 years ago

At the 31c3 somebody had shown or told the audience about an issue in the Xen hypervisor that allowed someone to break into the host from the guest.

chisleu• 11 years ago

I was told it was a series of bugs that made it possible.

bscanlan• 11 years ago

AWS have posted an update about related upcoming EC2 maintenance: https://aws.amazon.com/premiumsupport/maintenance-2015-03/

"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."

gnu8• 11 years ago

Why do the major Xen providers get advance access to the patches while my machines have to sit vulnerable for over a week?

eloff• 11 years ago

Presumably because making the patch public also makes the vulnerability public and they want to give the big players time to protect their customers.

jmiwhite• 11 years ago

This is explained in the Xen security policy, from the 'Embargo and disclosure schedule' heading.

http://www.xenproject.org/security-policy.html

danielweber• 11 years ago

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.

hiou• 11 years ago

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.

tptacek• 11 years ago

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.

pa7ch• 11 years ago

This is why SEL4 is awesome. http://ssrg.nicta.com.au/projects/seL4/

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.

chubot• 11 years ago

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.

j_mcnally• 11 years ago

#2 will blow your mind.

Five new undisclosed Xen vulnerabilities

Related Stories