[HN Gopher] Microsoft will take nearly a year to finish patching...
___________________________________________________________________
Microsoft will take nearly a year to finish patching new 0-day
Secure Boot bug
Author : LinuxBender
Score : 66 points
Date : 2023-05-13 16:39 UTC (6 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| qingcharles wrote:
| I understand their caution. They can't test on all the millions
| of combinations of PC hardware out there, and some of them are
| inevitably going to have their boot records toasted by this
| update, bricking the machines.
|
| This is a lose/lose situation for Microsoft.
| hackernewds wrote:
| Do you also understand the ripple effects of having a known
| zero day exploit open for a year? Lose/lose situation for the
| customers and their related networks, ie almost everyone in the
| world
| gambiting wrote:
| What would you do instead, if you were MS?
| rejectfinite wrote:
| He would brick the Windows install and install Arch
| instead.
| csdvrx wrote:
| It's sad, because they did some cool things with SecureBoot on
| X64: you can install your own keys and sign your Linux payloads
| to prevent an evil maid attack using a default Windows
| thumbdrive signed with Microsoft keys
|
| And I don't mean just the old/BlackLotus affected ones: you
| have full control of what you allow your system to run.
|
| Compare that with BootGuard which doesn't let you patch your
| Bios, like you'd want to do to fix PE32 modules :(
| nubinetwork wrote:
| I'm not surprised. UEFI has to publish the revocation keys, then
| board manufacturers have to update their BIOSes, then the OSes
| have to enforce them on their level... although tfa makes it
| sound like Microsoft is skipping the board manufacturers?
|
| I vaguely recall some keys being revoked a couple years ago, but
| I don't remember why. FWIW, here's a list of previous revocation
| keys... https://uefi.org/revocationlistfile/archive
| zauguin wrote:
| Usually systems have a KEK (key exchange key) from Microsoft
| installed, then Microsoft can revoke keys on their own withot
| involvement of the UEFI forum, board manufacturers or anyone
| else (Unless the KEK itself is compromised). They usually
| publish these revocations later on the UEFI website, but that's
| not necessarily blocking the rollout.
|
| The actual issue is that the revoked key is the key used by
| Windows, so revoking it makes Windows unbootable.
|
| Seems a bit weird to call this a Secure Boot vulnerability
| though since Secure Boot still works, it's just that a validly
| signed binary happens to be vulnerable and boots arbitrary
| stuff in a later stage. While this circumvents Secure Boot on
| all systems which allow booting Windows (so all systems where
| noone explicitly changes the Secure Boot setup), it sounds more
| like a Windows boot loader vulnerability than a Secure Boot
| issue.
| jmclnx wrote:
| No surprise with this, not like it was not predicted. I always
| uses legacy boot, so no issues for me.
|
| But did you read this ? How will grandma/pa be able to understand
| these instructions.
|
| https://support.microsoft.com/en-us/topic/kb5025885-how-to-m...
|
| Nuts, gotta love Microsoft and their great ideas. I wonder how
| complex the other patches talked about will be.
| rejectfinite wrote:
| This is for enterprise PC fleets... not home PCs. MS will auto
| enable in 2024.
| jlg23 wrote:
| > How will grandma/pa be able to understand these instructions.
|
| They are not the target audience and they are most probably not
| relying on bootable media?
| vladvasiliu wrote:
| They may be relying on the "recovery" partition or whatever
| it's called. Not sure if for PCs coming with windows pre-
| installed with a bunch of bloatware that's handled by windows
| directly so it could be updated by windows update, or if it's
| managed by the manufacturer, in which case it probably never
| will.
| csdvrx wrote:
| Windows will shrink its own partition as needed to create a
| recovery partition (type 0x27 in gdisk), which is just a
| NTFS partition.
|
| It depends on it to boot when bitlocker encryption is on:
| \EFI\Microsoft\Boot\bootmgfw.efi => bootmgr.efi => boot.sdi
| IIRC
|
| You can store other things in this 0x27 partition if you
| make it larger, like full ISO images like for Ubuntu Live:
| just place grubfmx64 in your \EFI partition, add it with
| efibootmgr and you can boot a baremetal Linux when WSL2
| doesn't cut it.
|
| Personally, I'm considering keeping a copy of the old
| bootloader and not updating the revocation DB as
| chainloading from bootmg to a Linux EKI with an entry when
| you press F8 could be a fun thing to add (I've read it
| could be done with Windows 7 and grub.efi but I have no
| experience with that)
| vladvasiliu wrote:
| What I've done on a pc that needs to dual boot and has a
| single drive is create a bigger /efi partition and store
| a unified kernel image that I boot directly with the
| uefi. No grub or shim or systemd-boot or whatever extra
| moving part. I can use the integrated uefi boot selector
| to switch to the non-default os.
|
| I've had this setup for a while now, and the multiple
| windows updates never bothered to make windows the
| default boot entry.
| csdvrx wrote:
| I do the same! My EFI partitions are always a few gigs,
| because I even stuff .isos into it for easy
| reinstall/rescue operations:)
|
| For people who are stuck with a 260 (or 100M) EFI,
| repurposing the 0x27 partition is easier: just shrink the
| end of your windows partition, and add what you gained to
| the 0x27 partition after backing up its content - no need
| to touch the other partitions!
|
| Shrinking a partition from the beginning (as what would
| be needed to get a larger EFI) can be harder
|
| > No grub or shim or systemd-boot or whatever extra
| moving part.
|
| Same, the arch way is just better! FYI you may want to
| add a grubfmx64.efi in there, to be able to select
| entries more easily for rescue ops. You also get a grub
| commandline.
|
| I don't like grub as a normal bootloader, but I like
| having its flexibility when I want to.
| out-of-ideas wrote:
| the target audience is all supported+patchable windows
| systems capable of secure boot; bootable media should be
| inclusive of all storage used: hdd, ssd, nvme, usb, cd, ect.
| hfkwer wrote:
| > I always uses legacy boot, so no issues for me.
|
| What do you mean by "no issues"? You're exactly as vulnerable,
| if not more, than someone who has secure boot enabled.
| smallstepforman wrote:
| Users that dual/triple boot are terrified that after a security
| update, their alternative systems wont boot. On my MacBookPro
| back in 2018/2019, an Win10 update prevented Win10 EFI
| BootManager from loading Win10 if it was installed on the 4th
| partition. Its sad how fragile their systems are after all these
| years.
| marketingLizard wrote:
| Now that it's unpatched, can we instead use something open that
| will be user mainatable and thus have a better chance of being
| secure?
| vladvasiliu wrote:
| Secure Boot by itself is plenty open and user maintainable. On
| my HP laptop I only have my own keys installed and it only
| boots my particular Linux install. It won't boot Windows at all
| nor regular Linux distros like Ubuntu. Other manufacturers
| intentionally limit their hardware, but that's nothing new,
| really.
|
| This particular issue is not so much about being able to manage
| the certificates in Secure Boot. Rather, you can't revoke the
| old signatures because many people rely on media having them
| (legitimately) and expect to be able to boot from that media.
| So now, those systems will boot anything with the old
| signature, such as a compromised windows bootloader that will
| happily accept some malware if asked nicely.
| datadeft wrote:
| Do you have a detailed article about this? I am trying to set
| up something like you mentioned
| vladvasiliu wrote:
| The page seems to have changed since I've set this up, but
| this is what I've followed: https://wiki.archlinux.org/titl
| e/Unified_Extensible_Firmware...
|
| The advice around the keys and signing is pretty generic.
| What's arch specific are the various integrations with the
| package manager than handle automatic signing of the kernel
| image after an upgrade.
|
| Lower on the page there's a section about signing MS's
| certificates, so you can dual-boot windows while using your
| own keys. I have that setup on my work laptop and it works
| fine.
| csdvrx wrote:
| > It won't boot Windows
|
| You can sign the Windows bootmg efi files with your own keys
| if you want.
| vladvasiliu wrote:
| According to the arch wiki that doesn't always work so well
| (didn't try it, though). But what does, is signing the MS
| certificate with your own key. I do that on my work laptop
| and it works well. I don't need windows on my personal one.
|
| https://wiki.archlinux.org/title/Unified_Extensible_Firmwar
| e...
| marketingLizard wrote:
| Sounds like it's pretty garbage though. Given that it's
| currently broken. How can my computers security depend on MS
| like that? Theyre not interested in my interests. I think
| I'll see if now I can replace it with something thats less
| conflicted, like coreboot.
|
| Can't wait until the other various secure enclave gets hacked
| so I can get rid of them too.
| vladvasiliu wrote:
| If you don't want to use it, can't you just disable it?
|
| Again, this isn't a failure of secure boot, but a windows
| security issue. Basically you can't prevent something from
| running (the bootloader) if you want to be able to... run
| it.
|
| Getting rid of secure boot and friends wouldn't change
| anything to this situation. Either you consider you're
| unlikely to be infected by black lotus or something
| similar, in which case you're fine (with SB enabled or
| disabled). Or you can be infected, in which case disabling
| secure boot doesn't actually do anything, since the rootkit
| will run fine without it.
|
| What is broken in this particular situation is not secure
| boot but the windows bootloader.
| marketingLizard wrote:
| If I can fully erase it, that's what I'll do. Disabling
| it is a comprise from a weakened position.
___________________________________________________________________
(page generated 2023-05-13 23:01 UTC)