[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]