Setting a boot password in the BIOS should mitigate adequately since initrd does not execute until after boot password entry.

On 11/17/2016 12:20 AM, Vít Šesták wrote:
According to the description, it looks likely to affect Qubes.

According to my experience, I remember getting in the shell (from a different 
reason) and it asked for a password. I believe this happened when upgrading to 
3.2 due to a mountpoint issue. This suggests that Qubes is not affected, but I 
haven't tried the exact scenario in Qubes.

The key question, however, is: How does it fit to your threat model? In my 
case, attacker would  need a physical access. In such casse, she can also boot 
from an USB device and do the same, maybe even more comfortably. I am aware 
that there are some examples (e.g. ATM) where this can be a real issue. Even 
for those cases, I doubt this is a massive threat. Such devices have usually a 
fairly limited keyboard, which can make the vulnerability unusable. (I am 
assuming that attacker cannot attach a custom keyboard.)

Regards,
Vít Šesták 'v6ak'


--

John R. Shannon

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/57a890cd-3e33-b905-2299-fd3f8a43aa79%40johnrshannon.com.
For more options, visit https://groups.google.com/d/optout.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to