# We needed this right now (Xen vulnerability)



## maounique (Jun 24, 2013)

Oh, well:
http://www.openwall.com/lists/oss-security/2013/06/20/4

http://www.cvedetails.com/cve/CVE-2013-1964/


----------



## kaniini (Jun 24, 2013)

Regarding CVE-2013-1964, Xen 4.2 is unaffected, and the transitive grants code is experimental, and thus shouldn't be enabled on any production hosts.

The other is mitigated by using PV-GRUB for untrusted kernel images, as PV-GRUB does the ELF parsing, not Xen itself.

In my opinion, not a big deal.


----------



## Francisco (Jun 24, 2013)

kaniini said:


> Regarding CVE-2013-1964, Xen 4.2 is unaffected, and the transitive grants code is experimental, and thus shouldn't be enabled on any production hosts.
> 
> The other is mitigated by using PV-GRUB for untrusted kernel images, as PV-GRUB does the ELF parsing, not Xen itself.
> 
> In my opinion, not a big deal.


Pretty sure most people are using XEN 3.x on solus.

Francisco


----------



## kaniini (Jun 24, 2013)

Francisco said:


> Pretty sure most people are using XEN 3.x on solus.
> 
> 
> Francisco


They won't be affected by CVE-2013-1964 at all then, as Xen 3 does not have anything other than non-transitive grants.

As for the other, using PV-GRUB mitigates it on any version of Xen, and as I recall it, Solus _does_ somehow magically support using PV-GRUB.


----------



## maounique (Jun 24, 2013)

kaniini said:


> They won't be affected by CVE-2013-1964 at all then, as Xen 3 does not have anything other than non-transitive grants.
> 
> As for the other, using PV-GRUB mitigates it on any version of Xen, and as I recall it, Solus _does_ somehow magically support using PV-GRUB.


I didnt say it affects providers using solus, just that a proof that any code is exploitable, no matter who made it, no matter if obfuscated or open source.

If you are looking at exploit lists, you wish you were a farmer instead.


----------



## Francisco (Jun 24, 2013)

Mao said:


> I didnt say it affects providers using solus, just that a proof that any code is exploitable, no matter who made it, no matter if obfuscated or open source.
> 
> If you are looking at exploit lists, you wish you were a farmer instead.


XEN has been exploited a ton of times though.

Francisco


----------



## kaniini (Jun 24, 2013)

I look at exploit lists from the perspective of whether or not they will affect my livelyhood.  Is there some other way I should be looking at them?


----------



## maounique (Jun 24, 2013)

While KVM not:

http://www.juniper.net/security/auto/vulnerabilities/vuln38158.html

As for ovz... who needs exploits when it DoSes itself from time to time...


----------



## kaniini (Jun 24, 2013)

Francisco said:


> XEN has been exploited a ton of times though.
> 
> 
> Francisco


Indeed, the vmsplice() Linux root exploit had a nice effect where it would crash some hypervisors by trashing the grant tables, in a similar way to CVE-2013-1964.  The good news is that the necessary codepath is usually disabled in that case


----------



## Francisco (Jun 24, 2013)

Mao said:


> While KVM not:
> 
> http://www.juniper.net/security/auto/vulnerabilities/vuln38158.html
> 
> As for ovz... who needs exploits when it DoSes itself from time to time...


I'm not saying KVM is perfect, just that XEN has had their hands messy more than a few times 

Francisco


----------



## maounique (Jun 24, 2013)

It is also much older


----------



## Marc M. (Jun 25, 2013)

We run Xen 4.1 on CentOS 6 with SolusVM.

I have patched Xen 4.1 against those vulnerabilities and made packages for CentOS 6 available here: http://repo.phoenixrpm.com

I've also posted this, however most people have missed it (my guess is that talking about security issues is more important to some than actually fixing them):

http://vpsboard.com/topic/896-phoenix-rpm-repository-updated-with-new-packages-nginx-naxsi-12-14-php-53-54-xen-41-xsa-55-patched-kernel-xen-34-for-centos-and-much-more/


----------



## MannDude (Jun 25, 2013)

Marc M. said:


> We run Xen 4.1 on CentOS 6 with SolusVM.
> 
> I have patched Xen 4.1 against those vulnerabilities and made packages for CentOS 6 available here: http://repo.phoenixrpm.com
> 
> ...


Probably because Xen isn't as commonly used around here. Bulk majority utilize OpenVZ, then KVM, then Xen. +1 though for the patch, and I hope it comes in handy. Hopefully those searching Google for a patch will stumble upon your thread.


----------



## Marc M. (Jun 25, 2013)

*@**MannDude* whei I said this:



MannDude said:


> my guess is that talking about security issues is more important to some than actually fixing them


I was referring that those nginx packages in my repository could be used with SolusVM and WHMCS to add a bit more security. Also, adding a htpasswd to the administration paths for WHMCS and SolusVM improves security quite a bit. If you want to really secure your installs you should also limit the IPs that can connect to the administration areas, as well as enable CloudFlare for SolusVM and WHMCS.


----------



## Aldryic C'boas (Jun 25, 2013)

Francisco said:


> I'm not saying KVM is perfect, just that XEN has had their hands messy more than a few times
> 
> 
> Francisco


And all I could think of were the white ganstas we saw setting up Xenserver at FH


----------



## Francisco (Jun 25, 2013)

Aldryic C said:


> And all I could think of were the white ganstas we saw setting up Xenserver at FH


Bahahaahaha.

Fran


----------



## kaniini (Jun 25, 2013)

Aldryic C said:


> And all I could think of were the white ganstas we saw setting up Xenserver at FH


<troll>See, Xen is better than KVM because it's gangsta-approved.</troll>


----------

