[prev in list] [next in list] [prev in thread] [next in thread]
List: qubes-devel
Subject: Re: [qubes-devel] Qubes Security Bulletin #22 (Critical bug)
From: Joanna Rutkowska <joanna () invisiblethingslab ! com>
Date: 2015-10-30 12:03:45
Message-ID: 20151030120344.GB11300 () work-mutt
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, Oct 30, 2015 at 08:10:28AM +0000, Axon wrote:
> Joanna Rutkowska:
> > Dear Qubes users,
> >
> > We have just released a new Qubes Security Bulletin (QSB #22) for
> > a critical bug in the Xen hypervisor:
> >
> > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/
> > qsb-022-2015.txt
> >
> > Please install the updates, immediately.
> >
> > Regards, joanna.
> >
> >
>
> From QSB #18 (XSA 123):
> > We see several problems that concern us about this vulnerability
> > and patching process:
> >
> > 1) It seems really difficult to understand why would anybody
> > design a structure like the one shown above, which uses a union to
> > store two, RADICALLY DIFFERENTLY TRUSTED data: an internal pointer
> > into hypervisor memory and VM-provided UNTRUSTED DATA? Such design
> > decision made by one of the core hypervisor developer is certainly
> > worrying. We're not sure if it would be more worrying if this was
> > done purposely vs by carelessness...
> >
> > 2) We are not entirely convinced if the way Xen Security Team
> > decided to address this vulnerability is really optimal, security
> > wise. It seems like a more defensive approach would be to get rid
> > of this dangerous construct of reusing the same memory for both an
> > internal pointer and VM-provided data. Apparently Xen developers
> > believe that they can fully understand the code, with all its
> > execution paths, for decoding x86 operands. This optimistic
> > attitude seems surprising, given the very bug we're discussing
> > today.
> >
> > 3) This lack of defensive programing and perhaps over confidence
> > (in ability to fully understand all the code paths) has been
> > demonstrated by the Xen Security Team also previously. In the
> > recently released XSA 109 [2], the official patch also seemed to
> > address the problem much earlier in the execution path rather than
> > at the actual offending instructions, i.e. those that performed
> > the NULL-dereference. While asked specifically about adding at
> > least an additional check on these instructions, the Xen developers
> > were unwilling to implement it implying potential performance
> > impact.
> >
> > 4) This is all certainly a bit disconcerting and we hope we could
> > start a bit more public debate on these issues, especially among
> > independent security researchers. We still believe Xen is currently
> > the most secure hypervisor available, mostly because of its unique
> > architecture features, that are lacking in any other product we are
> > aware of.
>
> From QSB #22 (XSA 148):
> > On the other hand, it is really shocking that such a bug has been
> > lurking in the core of the hypervisor for so many years. In our
> > opinion the Xen project should rethink their coding guidelines and
> > try to come up with practices and perhaps additional mechanisms
> > that would not let similar flaws to plague the hypervisor ever
> > again (assert-like mechanisms perhaps?). Otherwise the whole
> > project makes no sense, at least to those who would like to use
> > Xen for security-sensitive work.
> >
> > Specifically, it worries us that, in the last 7 years (i.e. all the
> > time when the bug was sitting there having a good time) so much
> > engineering and development effort has been put into adding all
> > sorts of new features and whatnots, yet no serious effort to
> > improve Xen security effectively. Because there have been, of
> > course, many more security bugs found in Xen over the last years
> > (as the numbering of this XSA suggests). True, majority of these
> > didn't affect Qubes OS, sometimes by pure luck, sometimes because
> > of the extra prudence we applied, many other times because of the
> > architectural decisions we made. Nevertheless, the bugs in Xen
> > are being found regularly, and this is no good news. For a type-1
> > hypervisor of the age and maturity of Xen, this simply should not
> > be happening. If it does, it suggests the development process is
> > not prioritizing security.
>
> After yesteday, is ITL now considering moving away from Xen as the
> (default) hypervisor for Qubes? Or is ITL's opinion that Xen is still
> our best bet?
Like with democracy and capitalism, Xen seems to be currently the best we can
do, in the short time horizon.
joanna.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJWM1ygAAoJEDOT2L8N3GcYOl0QANwYShEGC+tTnFeKznGvhpWU
sNl7TUKdac6taayFkzXKYkZlMUivLDzHbuln26YNEvgzt8Np676D9sx4rJxiQd8/
BE+ktqd0ZjxvQS7dmtzEYwT0OmGOn7wtp1Q0q4Qx/gVi+5DZOU49mMY7f9EVN8rA
w95iQoDQfaVvql3w/yV1RXq4+Wo2wGoSPlyZnjPeqOLpZEIr5AuX3aB3/6FrfeT+
hvd6kQoGxPS6Mpszi9SvvW/GJbYxoW81awG5jGULVrD0kX3MwbMWcxjIp+4vO9nx
Ik5Bt5GPhlAEUhKfFrFj9U7/n9EnKUvGpAaCtc20Q1dNcqPnDhG0KUN9rq+56RTz
uLyHyyy7zvpxRFAOXID8nPx8SGG7iJgPoGX/r810IfUdQHFbDEn8Ctoguo/nT3Re
ZYyPChhbJkQtfrJQIw5OAbenF5ZXrWuJcBSTKypCV3Hxka5ETM6aAmn5Tmqd0ZkR
DlnoFsajXSefNbAvjHdkoctGlnBgNj7g8efV8sfZOSiKr3H9fQ/yQ7U+7Tqnu8L1
n/R8ZgiwShptaaGYGL16B4VtpC8dLPOiVfUk55JhSLKDugATUjiH4Rq7RwMi2v4f
dD94Q5azVZjYhl5E0OV52u3SbbfCTHjiEnGvh8bf+aQCnMzCVVh0QcHDyEHi0pDm
dKY8NYnFJ+jn4pPPIpmU
=7UoZ
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/20151030120344.GB11300%40work-mutt. For \
more options, visit https://groups.google.com/d/optout.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic