Re:Five new undisclosed Xen vulnerabilities
by rgbrenner on Friday February 27, 2015 @12:15AM
(#9117295)
See ya later uptime... 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...
Re:Five new undisclosed Xen vulnerabilities
by mnordhoff on Friday February 27, 2015 @02:32AM
(#9117648)
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.
Re:Five new undisclosed Xen vulnerabilities
by rgbrenner on Friday February 27, 2015 @03:13AM
(#9117765)
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.
Re:Five new undisclosed Xen vulnerabilities
by kbar13 on Friday February 27, 2015 @04:21AM
(#9117957)
rackspace most likely uses hvm guests. I think they had freebsd before there was xen pv support
Re:Five new undisclosed Xen vulnerabilities
by yclept on Friday February 27, 2015 @08:08AM
(#9118604)
Rackspace has both HV and PV for most default linux images
Re:Five new undisclosed Xen vulnerabilities
by singlow on Friday February 27, 2015 @01:46AM
(#9117521)
Yeah. I had one server with over 900 days prior to Oct. It probably should have been rebooted for other reasons but thats the one that forced it.
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).
04:49:58 up 659 days