Re: [qubes-users] Cryptsetup Vulnerability affects QubesOS?
-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- -- 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/20161124224055.GZ1145%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Cryptsetup Vulnerability affects QubesOS?
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 -- 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/959c27bc-446b-593f-df95-885d4f9255f1%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Cryptsetup Vulnerability affects QubesOS?
On 11/19/2016 02:31 PM, Marek Marczykowski-Górecki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Nov 19, 2016 at 07:20:56PM +, Fred wrote: 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? 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- 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. -- 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/f7e034fc-15e5-aeb8-1ba6-f9fa64fbae35%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Cryptsetup Vulnerability affects QubesOS?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Nov 19, 2016 at 07:20:56PM +, Fred wrote: > 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? 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- -- 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/20161119193148.GX1145%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Cryptsetup Vulnerability affects QubesOS?
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? -- 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/a4d7d1ec901a8457f54936b2e27685b7%40email.gmsl.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Cryptsetup Vulnerability affects QubesOS?
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 -- 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/cc1a208a-b061-c626-4d6e-22b9d59d4948%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Cryptsetup Vulnerability affects QubesOS?
-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- -- 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/ee88ec9c-73e8-3185-4894-81cc06e8e054%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Cryptsetup Vulnerability affects QubesOS?
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. smime.p7s Description: S/MIME Cryptographic Signature
[qubes-users] Cryptsetup Vulnerability affects QubesOS?
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' -- 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/9741b25a-5d21-45ec-9c79-d09690e57e8c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Cryptsetup Vulnerability affects QubesOS?
On 16/11/2016 19:10, berthold_...@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. -- 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/72fa3b43-d246-c136-76b7-bbf214dd39cb%40gmsl.co.uk. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Cryptsetup Vulnerability affects QubesOS?
Does this affect QubesOS? https://threatpost.com/cryptsetup-vulnerability-grants-root-shell-access-on-some-linux-systems/121963/ -- 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/57ae4a42-40e8-1a8f-a645-ccb22b505c86%40riseup.net. For more options, visit https://groups.google.com/d/optout.
