Thinkpwn?

76 views
Skip to first unread message

el...@tutanota.com

unread,
Aug 13, 2016, 11:57:04 PM8/13/16
to qubes-users
Maybe this is a dumb question, but I can't seem to find any threads here on thinkpwn on the qubes group.
Should we be turning off our thinkpwn'd computers off until there are bios updates to correct thinkpwn?
Specifically, if we have...
single boot qubes?
dual boot with some other os (windows / osx)?

Lastly, perhaps more importantly, once a computer has been thinkpwn'd, is there any way to check?
In other words, is it no longer safe to buy a used computer with which to run Qubes off of (in case it has been breached by thinkpwn)?
From my understanding, even if you swap out the hard drive and change the os, the malicious software survives. That is huge, no?

There is a laymen's guide on github.. I am sure that every first-world nation (and at the very least the cryptolocker people--they made millions in two months last year) have ten to twenty people working on honing out the exploit.

Toss the old computers, or am I being too paranoid?

Andrew David Wong

unread,
Aug 14, 2016, 3:43:55 AM8/14/16
to el...@tutanota.com, qubes-users, Joanna Rutkowska
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Joanna tweeted about this on 2016-06-29:

"BTW, as @QubesOS isolates apps, networking, USB, etc away from UEFI
interfaces, this attack should not be a problem."

https://twitter.com/rootkovska/status/748122429235552256

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXsCEpAAoJENtN07w5UDAwQhwQALTnKPDrxFOAhqFoE2OWnPDW
OlUrdJEe2CeDRwIHHyXkx23U+EyXF3VcOAVDFKBD5wXOUSGH64AAG4J5uwD1Efsu
3e+YDx/Z8tw5AI1JjO+MnwdYnS+sgmQn9h1OrojBboS1bFqkftV3P/kSJ5kSdaas
x98apg4dWL+E59qZqA6KONpPjxfLc6uoQfu9wIPUX9vg1QQa/fH178gJJwsfnLbN
zvg/LAWWP3XsdRfqKm4D41Lnj2BHu/hUjSXfNZPELJAgXhTvJdQ2U/eSGxmjZ5Fy
oeEsEXbGtsyzyS7nL3qB4kHHBmGNU0oirl1v1DRc2LbiFBEVCFuShcw0XUwqrgpR
KdEgkpHfkyoxVPhZAY6Ma7yJR7vTrmNfLhCPyP8flwH02/5FG1BMkNe+VyMmfDpz
vRLgP4kg0PRub9qfQDf1NNgGTrL3cKAGbPAxEzpsvxS69lDaBXxvgUSaOXW14EnI
ufqnT3lv83eNabLUXnkl6Oz8pg6tAmBJV44gCM0LKrrKYlzu2iGL4iyKNgUZ1Cgb
4Ds9l471cbzeztCwmFYKeWo40cSrILtbRcTFXGmIAGHEvZsVUwbJIoyMLbAxPvhv
dhiZKQNH3jhYJSBWOZGlxtdXDcq3OsqCZPEhLmn2uibFVspU2JlGXTJ/H1kYSxlo
QOtEvn9Xb+JXkoLDB9Pz
=Jm16
-----END PGP SIGNATURE-----

el...@tutanota.com

unread,
Aug 14, 2016, 3:55:10 PM8/14/16
to qubes-users, el...@tutanota.com, joa...@invisiblethingslab.com
Just to clarify, that means that even if the UEFI is exploited, it does not matter with Qubes?

Joanna Rutkowska

unread,
Aug 15, 2016, 5:06:43 AM8/15/16
to el...@tutanota.com, qubes-users, Andrew David Wong
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Aug 14, 2016 at 12:55:10PM -0700, el...@tutanota.com wrote:
> Just to clarify, that means that even if the UEFI is exploited, it does not
> matter with Qubes?

Yes. Unless the isolation-provider that Qubes happens to be using -- currently
Xen -- is terribly buggy and fails at providing this isolation. Sadly, this was
the case with XSA 148 (last year[1]) and XSA 182 (just recently [2]) :(

We hope the move to SLAT-based memory virtualization in Qubes 4 would minimize
likelihood for similar bugs in the future (see [2] again).

I shall point out, however, that majority of other "critical Xen bugs" have not
affected Qubes to date, either because of various architecture decisions we made
(e.g. getting rid of qemu from Dom0, most backends treated as untrusted, running
in other-than-Dom0 domains, etc), or by a combination of luck and gut feeling
(e.g. not using 32-bit VMs, etc).

Thanks,
joanna.

[1] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt
[2] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJXsYYZAAoJEDOT2L8N3GcYFnEQANlqIJWhFHXvAIljGjZQwtl0
vgzkV0ZHA69OzPl5M4TvZhcUWgtTiOTTGjeHdUmkblCZEBLOCqakKQv1h4h+7I+6
oLtR5mKR4a6H7Mt9L5Ux5ciyRzx2oqDQpe7dehha/pOVMd3jj6niqJRTdhOSrVlB
GJD2BGNvoFa1hfSKEMBBs1SP7vgGCz2YWI/MoX7fpcM6g2XwvSYTQKpPnRbG/AUa
D6j6Gku0Rj+jDaiBDG4Iy6ymDbr7yW/7oYxOKXLpI8nj3UjZ0QIA2ym5dGb/hWjl
pmqDv5yKesCFedIUr/8SQzdwkhfQCbb8OYvXQBNoQNeAJxiT0eJFvD+9rohuVTdZ
KwLYKuUlCIrcxv+ULYSqPLm3GuzQAnJGi9eSw3N8t2UeHCDB2//fcihKzssZQeON
3h/U5Gj/IcXAITAq52/Euy1VinMwghC09HHR2lMJ8ZDuBAMaYOnLlOM8KGqMYUO0
5Q+iGxejjSnexVhMzBYIjm5m20e1cvDHEkTcoTfJ0r4CIGZyaLdJjjkKvpwm8tdN
0q5mippj+Sf4UlXFIQbrCE1jHVGL+KUUFilpMx8E4nFzhjIeN8EeBPzm861efNS6
qD2RowN6wVPa88v+kVGSRHgNxpZDDuSH5215+2MxUKrcx3oxdNPXKQ6RbCNKTk+n
wwNrXWQXiDy0koRjPVRQ
=CC3q
-----END PGP SIGNATURE-----

Joanna Rutkowska

unread,
Aug 15, 2016, 5:22:24 AM8/15/16
to el...@tutanota.com, qubes-users, Andrew David Wong
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Aug 15, 2016 at 11:06:32AM +0200, Joanna Rutkowska wrote:
> On Sun, Aug 14, 2016 at 12:55:10PM -0700, el...@tutanota.com wrote:
> > Just to clarify, that means that even if the UEFI is exploited, it does not
> > matter with Qubes?
>
> Yes.

Oh, I noticed you wrote 'exploited', while I originally understood
'exploitable'. So, if it is 'exploited', which I assume you meant 'already
compromised', then it's likely a game over, no matter what OS on the host.

joanna.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJXsYnHAAoJEDOT2L8N3GcYUR0P/i5goJ9TH09QbFRFysHMJKyz
4cm4xPI4IsskXWQJHbwD62332iGZ2UpYqK/NBixfj2q+UbwruF5BOVSTkdpsaJe/
Lu8qmqEHxBOqqmX+utnyJtvjob8Ranuj3IzCw0zcC03riUEuUz/YyvUEBoyPDyWb
KTbw1NJc3DrPGty8NW1hNbsGHNMNrvKwGA7rCl1kHdyZQ0WB4T2Ury2QpXeMYoD+
Jz9R3GXAH0ZhPOiqy4+5laWnl/kQ7MK5h1cUTvkFYUmX8j9kDuvpjmZ2sG5/tkC3
KH4uVXzRcHlj/Wa/ihKFPSgReRLDeQop/zPraMF0upZH/fcawfJSXdpD5YWDu5JN
sn6JDzYRO/tWOgTnWRYRgMFn/ILuyb56XO7F8DnFQOmo32smRJwUlhE+W5VnhEhf
ibYYsDEV7+GCIjxLuDL28o2/flPYdmed8YEpf6ilPidSHn/OahlRACx8DhP7acXV
e6an11/3GnQ5cUDp7jM0J+gx0rJ58jOgfS6KQ1WTLHpLQuPKV3OooG6qdYJav1NC
h2hEhDMrDU198wyB5KjnP8UzFZXZKj4P44+5ATIv2XoU7wmuTiaRe7Vg+jHdxg96
vpJ9Vwv+iY5jN1cB5Eh6MWS9j2Qlud/voDgxnwMqen33wp3w0nmC6VDL/1bD+KbN
wTBGjE0Im3VaXM57we/9
=w+Ko
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages