Hello, we are using 3.4.3 from Gitco.de on 64bit Centos 5.8 and we have PV guests 64bit. According to described security bug we are in danger. What do you suggest? Wait for gitco update or build xen own with patch? Br Peter
On Thu, Jun 14, 2012 at 1:35 PM, Peter Braun <xenware@gmail.com> wrote:> Hello, > > we are using 3.4.3 from Gitco.de on 64bit Centos 5.8 and we have PV > guests 64bit. > > According to described security bug we are in danger. > > > What do you suggest? Wait for gitco update or build xen own with patch?It depends :) If you use newer AMD processor, it shouldn''t matter. If you control all of your domU, you could probably wait, as it requires root privilege on domU to trigger the bug. However if you run (e.g.) a VPS-hosting where other people have control of the domU, you should build your own upgraded package immediately. FWIW, this is one of the example on how using vendor-provided packages would be useful. Redhat already released updated that address that vulnerability: https://access.redhat.com/security/cve/CVE-2012-0217 https://rhn.redhat.com/errata/RHSA-2012-0721.html -- Fajar
We are in the worst case: - intel cpu - domU not under control We will have to go own package way. Thanks Peter 2012/6/14 Fajar A. Nugraha <list@fajar.net>:> On Thu, Jun 14, 2012 at 1:35 PM, Peter Braun <xenware@gmail.com> wrote: >> Hello, >> >> we are using 3.4.3 from Gitco.de on 64bit Centos 5.8 and we have PV >> guests 64bit. >> >> According to described security bug we are in danger. >> >> >> What do you suggest? Wait for gitco update or build xen own with patch? > > It depends :) > > If you use newer AMD processor, it shouldn''t matter. > If you control all of your domU, you could probably wait, as it > requires root privilege on domU to trigger the bug. > However if you run (e.g.) a VPS-hosting where other people have > control of the domU, you should build your own upgraded package > immediately. > > FWIW, this is one of the example on how using vendor-provided packages > would be useful. Redhat already released updated that address that > vulnerability: > https://access.redhat.com/security/cve/CVE-2012-0217 > https://rhn.redhat.com/errata/RHSA-2012-0721.html > > -- > Fajar
Is there some scenario how to test that our config is affected? In this article: http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-escalation/#more-4865 is being mentioned about linux 2.6.16.5 is affected. Does this means that guest 2.6.18+ would be not able to abuse? Peter 2012/6/14 Peter Braun <xenware@gmail.com>:> We are in the worst case: > > - intel cpu > - domU not under control > > We will have to go own package way. > > Thanks > > Peter > > > > 2012/6/14 Fajar A. Nugraha <list@fajar.net>: >> On Thu, Jun 14, 2012 at 1:35 PM, Peter Braun <xenware@gmail.com> wrote: >>> Hello, >>> >>> we are using 3.4.3 from Gitco.de on 64bit Centos 5.8 and we have PV >>> guests 64bit. >>> >>> According to described security bug we are in danger. >>> >>> >>> What do you suggest? Wait for gitco update or build xen own with patch? >> >> It depends :) >> >> If you use newer AMD processor, it shouldn''t matter. >> If you control all of your domU, you could probably wait, as it >> requires root privilege on domU to trigger the bug. >> However if you run (e.g.) a VPS-hosting where other people have >> control of the domU, you should build your own upgraded package >> immediately. >> >> FWIW, this is one of the example on how using vendor-provided packages >> would be useful. Redhat already released updated that address that >> vulnerability: >> https://access.redhat.com/security/cve/CVE-2012-0217 >> https://rhn.redhat.com/errata/RHSA-2012-0721.html >> >> -- >> Fajar
On Thu, Jun 14, 2012 at 3:07 PM, Peter Braun <xenware@gmail.com> wrote:> Is there some scenario how to test that our config is affected?Not that I know of.> > In this article: > http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-escalation/#more-4865 > is being mentioned about linux 2.6.16.5 is affected. >That part is about how other OS, when used on bare metal, is also vulnerable to the bug. Linux (again, when used in bare metal) should not be affected by the bug anymore.> Does this means that guest 2.6.18+ would be not able to abuse?I''m not sure. Reading RH''s bugzilla page, it SEEMS to be so. Or to be accurate, when guests uses RHEL''s kernel (which contain CVE-2005-1764 and CVE-2006-0744 fixes), those guests will not be able to abuse that bug. Since you use centos, I''m not sure what''s the best way to confirm. Buy redhat support, perhaps, and ask them? -- Fajar
From what I understand, http://www.gitco.de/repo/ Gitco only provides the hypervisor and userspace tools, ie from the page: - These XEN-RPMS are for CentOS-5/RHEL-5 (x86_64) - They have been built from the sources of http://www.xen.org - It''s only the hypervisor, no changes on the kernel !!! Even with a Gitco provided hypervisor rpm, your dom0 is running with the CentOS provided kernel-xen, which can be updated with the fix. From a brief look this vulnerability does not impact the hypervisor.. right ? John
On Thu, Jun 14, 2012 at 7:19 PM, John Creol <iamcreo@yahoo.com> wrote:> From what I understand, http://www.gitco.de/repo/ Gitco only provides the hypervisor and userspace tools, ie from the page: > - These XEN-RPMS are for CentOS-5/RHEL-5 (x86_64) > - They have been built from the sources of http://www.xen.org > - It''s only the hypervisor, no changes on the kernel !!! > Even with a Gitco provided hypervisor rpm, your dom0 is running with the CentOS provided kernel-xen, which can be updated with the fix. > > From a brief look this vulnerability does not impact the hypervisor.. right ?The bug is on the hypervisor as well: https://bugzilla.redhat.com/show_bug.cgi?id=813428 What I haven''t been able to be sure from that bugzilla is whether you''ll be "safe" from that bug even if your hypervisor is vulnerable, IF.: - your domUs ONLY run "safe" (e.g. RH''s) kernels, or - your domUs only run newer kernels (and if that''s the case, what version is "new" enough) Also, even if that were the case, there''s the issue of "how do you make sure your domUs ONLY use the safe kernel if the domU is not within your control and it boots with pygrub/pvgrub" (which roughly means your users can change the running kernel with their own, possibly "unsafe" kernel. -- Fajar
On 14/06/2012 13:51, Fajar A. Nugraha wrote:> On Thu, Jun 14, 2012 at 7:19 PM, John Creol<iamcreo@yahoo.com> wrote: >> From what I understand, http://www.gitco.de/repo/ Gitco only provides the hypervisor and userspace tools, ie from the page: >> - These XEN-RPMS are for CentOS-5/RHEL-5 (x86_64) >> - They have been built from the sources of http://www.xen.org >> - It''s only the hypervisor, no changes on the kernel !!! >> Even with a Gitco provided hypervisor rpm, your dom0 is running with the CentOS provided kernel-xen, which can be updated with the fix. >> >> From a brief look this vulnerability does not impact the hypervisor.. right ? > The bug is on the hypervisor as well: > https://bugzilla.redhat.com/show_bug.cgi?id=813428 > >My understanding is that this is *only* a hypervisor issue, *not* a kernel issue. The only reason why an updated RHEL kernel-xen package fixes this, is because the kernel-xen package includes the Xen hypervisor. I''ve always thought the RHEL package name "kernel-xen" was misleading. They should have called it something like "xen-server" or something. Please someone correct me if I''m wrong
I''d also love to know if this instruction is available if VT is disabled. Basically, I run ~25 PV Linux domUs none of which has an old kernel and 1 HVM. (A FreeBSD box, with a user that I do not have to worry about) A malicious user could probably remove the bugfix from his linux kernel version and have a happy ride again, so this, well, sucks. Flipping something in BIOS would make me a lot happier. 2012/6/14 Jonathan Tripathy <jonnyt@abpni.co.uk>:>>> From a brief look this vulnerability does not impact the hypervisor.. >>> right ? >> >> The bug is on the hypervisor as well: >> https://bugzilla.redhat.com/show_bug.cgi?id=813428 >> >> > My understanding is that this is *only* a hypervisor issue, *not* a kernel > issue. The only reason why an updated RHEL kernel-xen package fixes this, is > because the kernel-xen package includes the Xen hypervisor. I''ve always > thought the RHEL package name "kernel-xen" was misleading. They should have > called it something like "xen-server" or something. > > Please someone correct me if I''m wrongDon''t know :> -- the purpose of libvirt is to provide an abstraction layer hiding all xen features added since 2006 until they were finally understood and copied by the kvm devs.
Hmm, ok double-reading the RH Bugzilla helped a lot. :> HVM=> Not affected So, assumedly, that includes a vulnerable OS as FreeBSD in a HVM domU. The great thing with FreeBSD is that you can actually update with pulling your hair out. The bad thing is the host reboots ahead... Florian -- the purpose of libvirt is to provide an abstraction layer hiding all xen features added since 2006 until they were finally understood and copied by the kvm devs.
On 15/06/12 00:51, Fajar A. Nugraha wrote:> Also, even if that were the case, there''s the issue of "how do you > make sure your domUs ONLY use the safe kernel if the domU is not > within your control and it boots with pygrub/pvgrub" (which roughly > means your users can change the running kernel with their own, > possibly "unsafe" kernel.My understanding (and I may be wrong) is if either the hypervisor is patched or the domu kernel that mitigates the vulnerability, so if you patch the hypervisor then you don''t have to worry about someone trying to exploit it with a vulnerable kernel. It''s not to hard to rebuild the .src.rpm to include the patch. I''ve already done it myself with the mayoung packages for RHEL6. Peter
On Thu, 2012-06-14 at 23:40 +0100, Florian Heigl wrote:> I''d also love to know if this instruction is available if VT is disabled.The sysret instruction is nothing to do with HVM/VT etc (and predates it) and cannot (AFAIK) be disabled and certainly not by turning off VT. However the hypervisor won''t use the sysret instruction to return to the guest so there is no way for an HVM guest to exploit this particular issue.> Basically, I run ~25 PV Linux domUs none of which has an old kernel and 1 HVM. > (A FreeBSD box, with a user that I do not have to worry about) > > A malicious user could probably remove the bugfix from his linux > kernel version and have a happy ride again, so this, well, sucks. > > Flipping something in BIOS would make me a lot happier. > > > 2012/6/14 Jonathan Tripathy <jonnyt@abpni.co.uk>: > > > >>> From a brief look this vulnerability does not impact the hypervisor.. > >>> right ? > >> > >> The bug is on the hypervisor as well: > >> https://bugzilla.redhat.com/show_bug.cgi?id=813428 > >> > >> > > My understanding is that this is *only* a hypervisor issue, *not* a kernel > > issue. The only reason why an updated RHEL kernel-xen package fixes this, is > > because the kernel-xen package includes the Xen hypervisor. I''ve always > > thought the RHEL package name "kernel-xen" was misleading. They should have > > called it something like "xen-server" or something. > > > > Please someone correct me if I''m wrong > > Don''t know :>The RH kernel-xen package contains both the kernel and the hypervisor in a single package (presumably in some way matched for supportability purposes). This issue is only a hypervisor issue, fixing the hypervisor means you don''t need to worry/care about guest kernels etc. There is some confusion around this because the same issue also effects some baremetal operating systems. Baremetal Linux was fixed in 2005, which helps add a (small) hurdle to guest users exploiting the issue. You need to trust your guest kernels because a malicious guest admin could unpatch their kernel in order to exploit this on a system running a vulnerable hypevisor. I hope that''s made things clearer rather than more confusing... Ian.
Apparently Analagous Threads
- Bug#677221: xen: Xen PV privilege escalation (CVE-2012-0217)
- CVE-2022-30550: Privilege escalation possible in dovecot when similar master and non-master passdbs are used
- CVE-2022-30550: Privilege escalation possible in dovecot when similar master and non-master passdbs are used
- Bug#490409: CVE-2008-2004: privilege escalation
- Bug#469654: xen-unstable: CVE-2008-0928 privilege escalation