[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: Franz <169101 () gmail ! com>
Date: 2015-10-30 10:22:02
Message-ID: CAPzH-qDoRjWQSGH+PZV0gZKE_Vm4AXUZ8Y7whTXFW3qv+ayPcw () mail ! gmail ! com
[Download RAW message or body]
On Fri, Oct 30, 2015 at 8:10 AM, Axon <axon@openmailbox.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> 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?
>
Being the situation so much worse than what originally thought, and no fast
solution in sight, I am seriously considering to move my vaultVM to an
airgapped machine, perhaps a cellphone or a mini-laptop with no network
connection.
Which is the advantage? If somebody is able to hack my Qubes laptop he'll
have to steal my credentials one by one and not all together, giving me
time to recognize the harm he is doing and loosing something, but not all.
Best
Fran
-----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJWMyXeAAoJEJh4Btx1RPV8qdIP/imOU9l36bDugMd8SgScqnx2
> 9nwualqWF+rbWblNzh0jwk0FxDXmcehm1RFWOFyz2W89Org5u1cWNhhFktvMSQLK
> VlK8AAoo/BAruT4GuxoxZUIer2yrMrGioRtPsAmOOr8CSQ1A8Icyk2bNjofoSS3a
> bw4dxQ+ELQCuTWAAF9IwfJInsToXmm35HkZRoqrgx5ZQc2BfU2gHTgdToBmrnrRo
> bhQSowGYhj1PAMqyNCtLRo8dcOb26HKnJz5gHxNAhkY5YrbrUKJ8AmDAfjUarVAt
> cBK0K4aLDlNMAtvdhkRwk39ZG53ZPwB9x6xg70/taCZ6JZN6qbKWtHaKDOWF/j4E
> 61rJwCzf3JooHVtSoz5GlMOZUQ3CvdtK5g3iUx6r2OPrsVjhTIRpmEe7+g+ogMc7
> B/gP20NJRg+hcP8orQNu/AGkTHeK/LQsrqkK81C1ll6xv58TAi3GK5tkTDJemKOY
> aXY8smHWgNksdn6zgdwjFCDH+TkezaeLQ8DnjoYNVxCtr14dxoNJgt0TZjMI+0d6
> Fpu5m9oiC2D+CcifUkFQAXplY7G7d0lXMOj4VXz07eCFNgTCLGrEB/bnDUZaFJDv
> N5NRuEbHT1OyyJwcDyXMb8me1zooiRvBNKNeYwoTJfL6QfkPvw/4dq7UqENOBEjM
> UyXhbeLDzrz8uxoOzPn+
> =e8AW
> -----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/563325F4.9060709%40openmailbox.org
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
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/CAPzH-qDoRjWQSGH%2BPZV0gZKE_Vm4AXUZ8Y7whTXFW3qv%2BayPcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Attachment #3 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct \
30, 2015 at 8:10 AM, Axon <span dir="ltr"><<a href="mailto:axon@openmailbox.org" \
target="_blank">axon@openmailbox.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
Joanna Rutkowska:<br>
<span class="">> Dear Qubes users,<br>
><br>
> We have just released a new Qubes Security Bulletin (QSB #22) for<br>
> a critical bug in the Xen hypervisor:<br>
><br>
> <a href="https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/" \
rel="noreferrer" target="_blank">https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/</a><br>
> qsb-022-2015.txt<br>
><br>
> Please install the updates, immediately.<br>
><br>
> Regards, joanna.<br>
><br>
><br>
<br>
</span>- From QSB #18 (XSA 123):<br>
> We see several problems that concern us about this vulnerability<br>
> and patching process:<br>
><br>
> 1) It seems really difficult to understand why would anybody<br>
> design a structure like the one shown above, which uses a union to<br>
> store two, RADICALLY DIFFERENTLY TRUSTED data: an internal pointer<br>
> into hypervisor memory and VM-provided UNTRUSTED DATA? Such design<br>
> decision made by one of the core hypervisor developer is certainly<br>
> worrying. We're not sure if it would be more worrying if this was<br>
> done purposely vs by carelessness...<br>
><br>
> 2) We are not entirely convinced if the way Xen Security Team<br>
> decided to address this vulnerability is really optimal, security<br>
> wise. It seems like a more defensive approach would be to get rid<br>
> of this dangerous construct of reusing the same memory for both an<br>
> internal pointer and VM-provided data. Apparently Xen developers<br>
> believe that they can fully understand the code, with all its<br>
> execution paths, for decoding x86 operands. This optimistic<br>
> attitude seems surprising, given the very bug we're discussing<br>
> today.<br>
><br>
> 3) This lack of defensive programing and perhaps over confidence<br>
> (in ability to fully understand all the code paths) has been<br>
> demonstrated by the Xen Security Team also previously. In the<br>
> recently released XSA 109 [2], the official patch also seemed to<br>
> address the problem much earlier in the execution path rather than<br>
> at the actual offending instructions, i.e. those that performed<br>
> the NULL-dereference. While asked specifically about adding at<br>
> least an additional check on these instructions, the Xen developers<br>
> were unwilling to implement it implying potential performance<br>
> impact.<br>
><br>
> 4) This is all certainly a bit disconcerting and we hope we could<br>
> start a bit more public debate on these issues, especially among<br>
> independent security researchers. We still believe Xen is currently<br>
> the most secure hypervisor available, mostly because of its unique<br>
> architecture features, that are lacking in any other product we are<br>
> aware of.<br>
<br>
- From QSB #22 (XSA 148):<br>
> On the other hand, it is really shocking that such a bug has been<br>
> lurking in the core of the hypervisor for so many years. In our<br>
> opinion the Xen project should rethink their coding guidelines and<br>
> try to come up with practices and perhaps additional mechanisms<br>
> that would not let similar flaws to plague the hypervisor ever<br>
> again (assert-like mechanisms perhaps?). Otherwise the whole<br>
> project makes no sense, at least to those who would like to use<br>
> Xen for security-sensitive work.<br>
><br>
> Specifically, it worries us that, in the last 7 years (i.e. all the<br>
> time when the bug was sitting there having a good time) so much<br>
> engineering and development effort has been put into adding all<br>
> sorts of new features and whatnots, yet no serious effort to<br>
> improve Xen security effectively. Because there have been, of<br>
> course, many more security bugs found in Xen over the last years<br>
> (as the numbering of this XSA suggests). True, majority of these<br>
> didn't affect Qubes OS, sometimes by pure luck, sometimes because<br>
> of the extra prudence we applied, many other times because of the<br>
> architectural decisions we made. Nevertheless, the bugs in Xen<br>
> are being found regularly, and this is no good news. For a type-1<br>
> hypervisor of the age and maturity of Xen, this simply should not<br>
> be happening. If it does, it suggests the development process is<br>
> not prioritizing security.<br>
<br>
After yesteday, is ITL now considering moving away from Xen as the<br>
(default) hypervisor for Qubes? Or is ITL's opinion that Xen is still<br>
our best bet?<br>
</blockquote><div><br></div><div>Being the situation so much worse than what \
originally thought, and no fast solution in sight, I am seriously considering to \
move my vaultVM to an airgapped machine, perhaps a cellphone or a mini-laptop with no \
network connection. <br><br>Which is the advantage? If somebody is able to hack my \
Qubes laptop he'll have to steal my credentials one by one and not all together, \
giving me time to recognize the harm he is doing and loosing something, but not \
all.<br><br></div><div>Best<br></div><div>Fran<br></div><div><br><br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">-----BEGIN PGP SIGNATURE-----<br> <br>
iQIcBAEBCgAGBQJWMyXeAAoJEJh4Btx1RPV8qdIP/imOU9l36bDugMd8SgScqnx2<br>
9nwualqWF+rbWblNzh0jwk0FxDXmcehm1RFWOFyz2W89Org5u1cWNhhFktvMSQLK<br>
VlK8AAoo/BAruT4GuxoxZUIer2yrMrGioRtPsAmOOr8CSQ1A8Icyk2bNjofoSS3a<br>
bw4dxQ+ELQCuTWAAF9IwfJInsToXmm35HkZRoqrgx5ZQc2BfU2gHTgdToBmrnrRo<br>
bhQSowGYhj1PAMqyNCtLRo8dcOb26HKnJz5gHxNAhkY5YrbrUKJ8AmDAfjUarVAt<br>
cBK0K4aLDlNMAtvdhkRwk39ZG53ZPwB9x6xg70/taCZ6JZN6qbKWtHaKDOWF/j4E<br>
61rJwCzf3JooHVtSoz5GlMOZUQ3CvdtK5g3iUx6r2OPrsVjhTIRpmEe7+g+ogMc7<br>
B/gP20NJRg+hcP8orQNu/AGkTHeK/LQsrqkK81C1ll6xv58TAi3GK5tkTDJemKOY<br>
aXY8smHWgNksdn6zgdwjFCDH+TkezaeLQ8DnjoYNVxCtr14dxoNJgt0TZjMI+0d6<br>
Fpu5m9oiC2D+CcifUkFQAXplY7G7d0lXMOj4VXz07eCFNgTCLGrEB/bnDUZaFJDv<br>
N5NRuEbHT1OyyJwcDyXMb8me1zooiRvBNKNeYwoTJfL6QfkPvw/4dq7UqENOBEjM<br>
UyXhbeLDzrz8uxoOzPn+<br>
=e8AW<br>
-----END PGP SIGNATURE-----<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group.<br> To unsubscribe from this group and stop receiving \
emails from it, send an email to <a \
href="mailto:qubes-devel%2Bunsubscribe@googlegroups.com">qubes-devel+unsubscribe@googlegroups.com</a>.<br>
To post to this group, send email to <a \
href="mailto:qubes-devel@googlegroups.com">qubes-devel@googlegroups.com</a>.<br> To \
view this discussion on the web visit <a \
href="https://groups.google.com/d/msgid/qubes-devel/563325F4.9060709%40openmailbox.org" \
rel="noreferrer" target="_blank">https://groups.google.com/d/msgid/qubes-devel/563325F4.9060709%40openmailbox.org</a>.<br>
</font></span><div class="HOEnZb"><div class="h5">For more options, visit <a \
href="https://groups.google.com/d/optout" rel="noreferrer" \
target="_blank">https://groups.google.com/d/optout</a>.<br> \
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group.<br /> To unsubscribe from this group and stop \
receiving emails from it, send an email to <a \
href="mailto:qubes-devel+unsubscribe@googlegroups.com">qubes-devel+unsubscribe@googlegroups.com</a>.<br \
/> To post to this group, send email to <a \
href="mailto:qubes-devel@googlegroups.com">qubes-devel@googlegroups.com</a>.<br /> To \
view this discussion on the web visit <a \
href="https://groups.google.com/d/msgid/qubes-devel/CAPzH-qDoRjWQSGH%2BPZV0gZKE_Vm4AXU \
Z8Y7whTXFW3qv%2BayPcw%40mail.gmail.com?utm_medium=email&utm_source=footer">https://gro \
ups.google.com/d/msgid/qubes-devel/CAPzH-qDoRjWQSGH%2BPZV0gZKE_Vm4AXUZ8Y7whTXFW3qv%2BayPcw%40mail.gmail.com</a>.<br \
/> For more options, visit <a \
href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br \
/>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic