Re: [qubes-devel] R4.0 - question about VM startup ordering during boot

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Jan 25, 2018 at 02:21:35PM +0200, Ivan Mitev wrote:
> On 01/25/18 13:27, Marek Marczykowski-Górecki wrote:
> > So, the question is why sys-net crashes. Take a look at
> > /var/log/xen/console/guest-sys-net.log and
> > /var/log/qubes/vm-sys-net.log.
> 
> /var/log/qubes/vm-sys-net.log didn't have any helpful info, but I see some
> panic logs in guest-sys-net.log ; I'll try to debug it when time allows.

Can you post this panic messages? I think I've hit exactly the same
problem once but mine logs didn't have any details on sys-net crash
(just cut during its startup). And I can't reproduce it again...

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlptFl0ACgkQ24/THMrX
1yyz5gf+Mi2YbDmopIvlxANTP2aUgCaN9tgJt0pRqz6l6wuAqDFQRRbHB6BPnrI+
oRYc50jaIU+GSUcSCzGJfZwzHeuVDxhobKvz/JCyV3mOAJKGib+GDwx0ou6sE7BX
o46xoaK+kxMzTOzNu9YwNnEmJobadO1e3ElW+UGJkE1jYBmeDta1U/A75U+ywTv9
jjV5lFxDG9xGRwTV0rPwK58WhHOR+p/4MNU5sAQUOwLPzsWhTj1mUsQJi+1OxAw3
1OWlOvEPzq1K0J1IUK8d39TW+3WOBREs9460ducbYpSo7pgED2Aw6QPMDIAR4acL
v4ozBzCtz2cfErk4Dpe/0+KyOid8eA==
=wII/
-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+unsubscr...@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/20180128001629.GC20612%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Re: [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

[Ed]

On 01/24/2018 04:29 AM, Andrew David Wong wrote:


## Qubes 3.2

Previously, we had planned to release an update for Qubes 3.2 that would
have made almost all VMs run in PVH mode by backporting support for this
mode from Qubes 4.0. 


Out of curiosity, is this still going to happen?  I would love to see 
this if possible, not only helping mitigate Meltdown without the 
performance penalty (I believe), but also would give a nice general 
security boost to 3.2


Thanks,
Ed

--
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+unsubscr...@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/p4a6db%248qa%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] R4.0-rc4 installation image considerations

[Ivan Mitev]

Hi Andrew,

On 01/27/18 15:31, Andrew Clausen wrote:

Hi Ivan,

On 27 January 2018 at 12:57, Ivan Mitev  wrote:


I don't see the benefit of using a DVD (we're talking about USB DVD
readers here) but maybe it's only me being thick...
If the machine used to copy or checksum the payload/iso is compromised,
then IMO it's already "game over" so I don't see how using a true read-only
medium vs a regular flash drive would help.



The idea is that you use many machines to checksum the payload.  Each
machine would have its own DVD device.


Ah, I see; in this case I agree that a DVD should give you greater 
("reasonable" ?) confidence that the install iso is legit compared to 
writable medias, provided you have enough machines and readers to test.


Re-reading the whole thread I'm not sure that the other parent posters 
had this idea in mind though...

Assuming the machine is not compromised and the payload/iso is legit,



But I was assuming the opposite!  The challenge is: how can you make a
secure machine out of insecure machines?



the only way for the bad USB device to modify the data would be on-the-fly:

- when writing the iso to the medium (in which case using a
write-once-then-read-only doesn't help at all vs using a writable medium)

- when reading it, for instance at boot, presenting different data to
different machines like you mentioned.

But:

  1- How really feasible is it to implement this attack ? It would require
tremendous processing power to properly alter the payload when it's been
copied to the medium; it would also require tailoring the attack to qubes'
isos, thus making it a targeted attack; I imagine that if you get to that
point you probably have more important problems.



In a targeted attack by the local government, I would think it's a moderate
fixed cost (e.g. one engineer spending about 3 months on it), with a low
marginal cost for each victim to be attacked.  If it's a foreign government
or organised crime, then interdiction becomes more expensive.  So they
might need to add in a physical surveillance element as well, e.g. some
kind of radio signal to tell the USB stick remotely that it should activate
the attack.  Much cheaper than the 24/7 physical surveillance that many
activists and some journalists are under at sensitive moments.


I wrote "tremendous processing", not "tremendous manpower": whatever the 
manpower and time spent by clever minds, I don't see how the USB 
hardware of a DVD reader or a flash drive could cope with on-the-fly 
analysis and modification of the data "passing by" at full read speed.


The attack mentioned by Sebastian - presenting different data to the 
host at boot time - is likely within the realm of USB hardware/firmware 
resources because there is enough time to analyze only a small amount of 
read data. In case you managed to get reasonable confidence that your 
medium is legit with the technique you describe, you could assume that 
it won't contain a "bad" alternate image so the attack above won't work. 
Your host's USB hardware could still be compromised though.


I now see what your setup achieves so thanks for your reply - it's 
always interesting to see what other people are doing even if I don't 
need to be that paranoid - fortunately !


Best,
Ivan

--
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+unsubscr...@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/45fd78e8-f45c-33ea-8e58-d84e08d13b9b%40maa.bz.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] R4.0-rc4 installation image considerations

[Andrew Clausen]

Hi Ivan,

On 27 January 2018 at 12:57, Ivan Mitev  wrote:

> I don't see the benefit of using a DVD (we're talking about USB DVD
> readers here) but maybe it's only me being thick...
> If the machine used to copy or checksum the payload/iso is compromised,
> then IMO it's already "game over" so I don't see how using a true read-only
> medium vs a regular flash drive would help.
>

The idea is that you use many machines to checksum the payload.  Each
machine would have its own DVD device.

A "physical write protect switch" is only going to be routed into that chip
>> through a GPIO, so it does *not* protect against this attack. Write-protect
>> on or off, most of the USB protocol logic inside the controller must be
>> working in order to serve read requests.
>>
>> DVDs fare better in this scenario. Even though you could also attack the
>> reader firmware, the attacker has only one (large) static payload read by
>> the firmware (the DVD). In case of the USB drive, the attacker has an
>> interactive session over a complex, multi-layer protocol presenting much
>> more attack surface.
>>
>
> Assuming the machine is not compromised and the payload/iso is legit,


But I was assuming the opposite!  The challenge is: how can you make a
secure machine out of insecure machines?


> the only way for the bad USB device to modify the data would be on-the-fly:
>
> - when writing the iso to the medium (in which case using a
> write-once-then-read-only doesn't help at all vs using a writable medium)
>
> - when reading it, for instance at boot, presenting different data to
> different machines like you mentioned.
>
> But:
>
>  1- How really feasible is it to implement this attack ? It would require
> tremendous processing power to properly alter the payload when it's been
> copied to the medium; it would also require tailoring the attack to qubes'
> isos, thus making it a targeted attack; I imagine that if you get to that
> point you probably have more important problems.
>

In a targeted attack by the local government, I would think it's a moderate
fixed cost (e.g. one engineer spending about 3 months on it), with a low
marginal cost for each victim to be attacked.  If it's a foreign government
or organised crime, then interdiction becomes more expensive.  So they
might need to add in a physical surveillance element as well, e.g. some
kind of radio signal to tell the USB stick remotely that it should activate
the attack.  Much cheaper than the 24/7 physical surveillance that many
activists and some journalists are under at sensitive moments.

So overall, I think lots of attackers -- including big companies (e.g. oil,
mining, pharma), organised crime, local and foreign governments -- would
find this attack promising.

We know from Snowden that at least one big agency likes targeting
developers and system administrators.  I would expect that everyone on this
mailing list is a target, just because they are on the list.

  2- both the DVD reader and flash drive have a USB firmware, so how would
> the DVD reader's firmware be more "secure" than the USB flash drive's one ?
>

Because you never plug the DVD reader into an insecure machine, only the
fresh new one.

Kind regards,
Andrew

-- 
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+unsubscr...@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/CAAXZBWKdtAeB5j9Hqf0jNTwEUWgJRAweqO_KwEEJjahyQLST8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] R4.0-rc4 installation image considerations

[Ivan Mitev]

On 01/27/18 13:33, Sebastian Götte wrote:

On 01/22/2018 08:33 AM, Peter Todd wrote:

Note that flash drives with physical write protect switches are available, such
as the Kanguru FlashBlu30 line.

While better than a regular r/w USB drive, I would not actually trust these. 
There's only going to be a regular USB flash controller inside, and the 
firmware on that one is just as good as the firmware on other USB drives.

The type of attack DVDs prevent is one where a compromised "download" or 
"checksum" machine compromises the USB drive firmware. The compromised USB drive then 
presents different data to different machines, e.g. the original iso to anyone checksumming and a 
modified iso to anyone booting. This attack requires a compromise of the USB flash drive controller 
via USB. This is realistic and has been demonstrated in the past.


I don't see the benefit of using a DVD (we're talking about USB DVD 
readers here) but maybe it's only me being thick...
If the machine used to copy or checksum the payload/iso is compromised, 
then IMO it's already "game over" so I don't see how using a true 
read-only medium vs a regular flash drive would help.



A "physical write protect switch" is only going to be routed into that chip 
through a GPIO, so it does *not* protect against this attack. Write-protect on or off, 
most of the USB protocol logic inside the controller must be working in order to serve 
read requests.

DVDs fare better in this scenario. Even though you could also attack the reader 
firmware, the attacker has only one (large) static payload read by the firmware 
(the DVD). In case of the USB drive, the attacker has an interactive session 
over a complex, multi-layer protocol presenting much more attack surface.


Assuming the machine is not compromised and the payload/iso is legit, 
the only way for the bad USB device to modify the data would be on-the-fly:


- when writing the iso to the medium (in which case using a 
write-once-then-read-only doesn't help at all vs using a writable medium)


- when reading it, for instance at boot, presenting different data to 
different machines like you mentioned.


But:

 1- How really feasible is it to implement this attack ? It would 
require tremendous processing power to properly alter the payload when 
it's been copied to the medium; it would also require tailoring the 
attack to qubes' isos, thus making it a targeted attack; I imagine that 
if you get to that point you probably have more important problems.


 2- both the DVD reader and flash drive have a USB firmware, so how 
would the DVD reader's firmware be more "secure" than the USB flash 
drive's one ?


But then, I'm not a security expert and I may be talking total nonsense 
:) - I'd be happy to be proved wrong and learn something in the process...


Cheers,
Ivan

--
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+unsubscr...@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/7438ac52-2a6c-be7a-0dc0-64fd41baaf98%40maa.bz.
For more options, visit https://groups.google.com/d/optout.