Cryptsetup Vulnerability affects QubesOS?

[bertho...@web.de]

Does this affect QubesOS?

https://threatpost.com/cryptsetup-vulnerability-grants-root-shell-access-on-some-linux-systems/121963/

[Fred]

On 16/11/2016 19:10, bertho...@web.de wrote:
> Does this affect QubesOS?
>
> https://threatpost.com/cryptsetup-vulnerability-grants-root-shell-access-on-some-linux-systems/121963/
>

Looks like a fairly low priority to me. You can get initramfs shell in a
Busybox and have access to /boot (on some systems) and see the encrypted
drives. Some articles seemed to imply that you'd have access to the
decrypted data (which isn't possible!).

A good time to ask if Qubes encrypts /boot in it's LUKS setup. I've not
checked myself.

You'd get the same effect if you boot via GRUB to an initrd shell.

[Vít Šesták]

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]

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

--

John R. Shannon

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-11-16 13:31, Fred wrote:
> A good time to ask if Qubes encrypts /boot in it's LUKS setup. I've not
> checked myself.
>

By default, Qubes does not encrypt /boot. Traditionally, that's because doing so would render the
system unbootable. However, that's no longer true with newer versions of GRUB, which are now capable
of booting from encrypted block devices. So, it's worth considering for Qubes. Tracking:

https://github.com/QubesOS/qubes-issues/issues/2442

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

iQIcBAEBCgAGBQJYMD17AAoJENtN07w5UDAwzSkP+wQ2j9InSiYCsGR0fWFECymo
Cb0VzO+07YC6fC2XMQXZk8szzc82CTfH7kPo0qWz6kHNWT7OXnF72X5cZviGtl1w
yhKjCiE/oD4R9upUzH2Pe67P+EKs7mpoi4k2VCC9qkAmnjLBKwyNl1Li4a3nlL6a
PQ+BfOGYr6yQuBKDrs4v5oP0pabQIYHq0aXbXiuPLio3RCUzPBGIvL5Tod+EPxSJ
QjhPqKK186XEjHQBn3H9mg4dC0iM2c/2eLloRviv8sxTrytX8DJMudgfVn6N9ni6
rU1V+6qKxKOojOz0dbMAYKA4hqoeYwcXW99jWl0wkrVeOA2dHv+etZZ4OjzVZK/m
5+Q5BS6xdLntZybbxkCGYjkLHN8bZy2Ka/YLO5glyI5yz3NIY55UFF9P5YNgLUHK
YAVuWxfTlpWqak/0VV1jLPsHABz2u2rCx2zwm4iYEmpSVWZpNRVy4QYhiGhSgWlt
0UrixWjb++8SACVIovNeJY82BNUZrySaMLv7aUqMwCsGTk6iGnjIc/xfjoB4lyJ4
a83B0KgXKxn7YLfr84456eoe5BIbzJK5y3ybA9eV7yNcDmXmPvyub7sa2txvB6yH
zmfYlkV8samTyXAMp8KFH4lbDzjbmNt5H1DqejA+QmHTnUIgzLgwqKCpt0KGQ3Up
MDwA6rj2CEBMhzHZhvU/
=krSf
-----END PGP SIGNATURE-----

[Achim Patzner]

Am 19.11.2016 um 12:54 schrieb Andrew David Wong:
> By default, Qubes does not encrypt /boot. Traditionally, that's
> because doing so would render the
> system unbootable. However, that's no longer true with newer versions
> of GRUB, which are now capable
> of booting from encrypted block devices.

There is still the option of grub-less EFI booting. With exotic setups
like mine which is getting its boot loader from an external USB device
that unlocks boot and compares checksums of relevant files to a table
stored on that external device.


Achim

[Fred]

On 2016-11-19 11:54, Andrew David Wong wrote:
> On 2016-11-16 13:31, Fred wrote:
>> A good time to ask if Qubes encrypts /boot in it's LUKS setup. I've
>> not
>> checked myself.
>>
>
> By default, Qubes does not encrypt /boot. Traditionally, that's
> because doing so would render the
> system unbootable. However, that's no longer true with newer versions
> of GRUB, which are now capable
> of booting from encrypted block devices. So, it's worth considering
> for Qubes. Tracking:
>
> https://github.com/QubesOS/qubes-issues/issues/2442

Yup. I know these days GRUB supports LUKS and things like mdadm, LVM etc
so the days are hopefully gone since people need to worry about the
position of /boot on disk or which esoterica are required to boot (and
any intitrd issues).

I guess the bigger question is if it actually provides any real added
protection? Someone can still re-install GRUB by booting from other
media and reinstalling GRUB. If the authenticity of /boot can also be
verified then maybe it does? But once physical access is gained the game
is over I guess?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Yes, exactly - if any of the boot chain element can be tampered with,
attacker can subvert it to intercept disk password and/or infect further
elements. It doesn't matter if that's whole /boot, or just stage1 of
GRUB in MBR.
The situation is somehow better when your firmware can handle disk
encryption (like Coreboot with Linux or Grub payload can) - in this case
the whole disk can be encrypted and attacker would need to re-flash the
firmware - which is somehow harder, take more time etc. But still
doable...

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYMKijAAoJENuP0xzK19cs770H/iKHTrMfdbFJSu53orcYNAVP
QLwDKzg7FVLHqcHYzwWe8Cu0pRxwHZwFzFZFyH6de96EmCa9FehJzuTFefUvOZ0T
HJ9ilXuIzpiarzxPO9UISLnhd1Qg/5xOWy6e7DS1BjWXsXjakek2/h+/wIsy8FCV
B0SFFFTo6Yiuxy0gThb1cNmLMlORCrVzt5mlENRyxz6KfmmM7mDhSaf7+hhfXAkX
28mz0jvuTqs56iJ07E9poWOCy5nDGAAposlp7GJSKmngMXQxPpdTOmXoSNMaPwii
BxnvPgyzBEoPg3FDPdUHsAOFPFy+0WeBxlpA6ykQ5qAZ9NsuWG3esYpIoPmdhRM=
=rNAe
-----END PGP SIGNATURE-----

[Tai...@gmx.com]

Or considering as coreboot (and the proprietary firmwares) doesn't
initialize IOMMU (yet), a DMA attack in the pre-linux dma prot initl
window is also a viable option.
Turtles all the way down man.

[Eva Star]

On 11/19/2016 10:31 PM, Marek Marczykowski-Górecki wrote:

> Yes, exactly

Is it possible to check non encrypted boot part of the disk for
checksums after OS was loaded and warn user about some changes? ( or
check some files on boot part)
Is it a good idea?

Or maybe some USB disk with loader which will do the same. And user
User periodically will be able to check his disk.

--
Regards

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Nov 25, 2016 at 12:19:14AM +0300, Eva Star wrote:
> On 11/19/2016 10:31 PM, Marek Marczykowski-Górecki wrote:
>
> > Yes, exactly
>
> Is it possible to check non encrypted boot part of the disk for checksums
> after OS was loaded and warn user about some changes? ( or check some files
> on boot part)
> Is it a good idea?

If someone have planted some malware there, he/she can also replace your
integrity checking tool. So such solution will not be bulletproof.

> Or maybe some USB disk with loader which will do the same. And user User
> periodically will be able to check his disk.

This would be better. Or you can go one step further - store /boot on
some USB stick. Or two steps further - use AEM with that.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYN2x5AAoJENuP0xzK19csaesH/jxwp92Tv/96utIuPaMShfIx
PtiNeZT/98kMrdBNLwrJHH6D/eio8v+3wOdK5gNkGxQs8W4IezOLf21ja1T1cNRe
5gG5FgUafayKu+0nPBpSgpK2vO3QubQPOqKRaE3YBGJcByRpCRgDqqzP6h3BNmoa
MBSOI6pUKAu6CWN5wryNOUv/lvfG9fxrCKcSIB94f7AV5yBMJ3hIJluE94/tvb8E
qobrPWFHMZMRa5upUjxNuEfGSuwhdfgymeGUOqc8bokoScA4cnLVJRxbdowcNILW
6uh//37IvU6rjlkKtpfiDaW4Yvxntx9sPBiBEuwuoveWr7SPyvKKTnJCgL4BMvI=
=+axr
-----END PGP SIGNATURE-----