WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: grub2 bug may break secure boot on Windows and Linux  (Read 1438 times)

aus9

  • Guest
grub2 bug may break secure boot on Windows and Linux
« on: July 29, 2020, 09:46:09 PM »
https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/

Quote
The problem also extends to any Windows device that uses Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority. Thus the majority of laptops, desktops, servers and workstations are affected,

@PDP-8
I do not want to be accused of being a click baiter but that link has a stack of info on UEFI and how vendors work with third party and shims and stuff that might be worth a click?

no pressure feel free to ignore me ;D

Offline PDP-8

  • Hero Member
  • *****
  • Posts: 915
Re: grub2 bug may break secure boot on Windows and Linux
« Reply #1 on: July 29, 2020, 10:58:56 PM »
Well, hope they update grub.  Interesting article, but as we know, security is a process, not just a single issue.

So many ways this can go off the rails, I don't want to go there.

However, for total security, just do what I do:

Run Simeon Cran's MYZ80 emulator.  In a dosbox.  Inside Linux.  It's where I play Zork and have all my financial stuff stored in Wordstar CP/M format. :)

I get a perverse pleasure every few years doing this - and it still is 100 times faster than it was back then. :)

Some old info here:
http://forums.debian.net/viewtopic.php?t=66644

That dude from Queensland certainly had his act together on the CP/M front.
« Last Edit: July 29, 2020, 11:03:53 PM by PDP-8 »
That's a UNIX book! - cool  -- Garth

Offline PDP-8

  • Hero Member
  • *****
  • Posts: 915
Re: grub2 bug may break secure boot on Windows and Linux
« Reply #2 on: July 30, 2020, 03:53:57 AM »
Ok, looking at it a bit more seriously - I needed something a bit closer to my level to understand, especially how it relates to grub.

https://www.theregister.com/2020/07/29/grub2_code_exec_flaw/

To me, is sure looks like promoting ISO BOOTING would help prevent that overflow trigger targeting grub.cfg on the next reboot!

I do that already on some of my projects, picking up embedded extensions from another iso, or use custom setups simply starting persistence elsewhere with tce-setdrive, tce= directives etc etc.  But many of my TC sticks are ISO BOOT already, not on writable filesystems.  Just my choice.

However, as noted, by the time one gets to this point security wise, you've already lost the keys to the kingdom.  This just piles-on. :)

And, even though I favor iso-boot, if anyone thought of running TinyCore in an enterprise environment should be immediately fired.  Home use, ok.


That's a UNIX book! - cool  -- Garth