Microsoft will take nearly a year to finish patching new 0-day Secure Boot bug | Hacker News Reader

Microsoft will take nearly a year to finish patching new 0-day Secure Boot bug

arstechnica.com

91 pointsLinuxBender44 comments

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.

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

What would you do instead, if you were MS?

He would brick the Windows install and install Arch instead.

Not all "zero day" is created equally.

The vast majority of home users have never heard of secure boot, which defaults to off. Every corporate network I've walked into I have been the one to push it, as most have never heard of it. Both Microsoft and aws only recently introduced support in the cloud environments, so the majority of cloud hosted environments have not turned it on (which requires replacing the vm). It is far from almost everyone in the world who is even in a position to be impacted by a secure boot bypass.

Secure Boot is required to run Windows 11.

I think that’s inaccurate. Secure Boot capability is an install ‘requirement,’ but you definitely don’t have to switch it on.

I believe it defaults to on, at least on most systems designed to run Windows

There is literally no such thing as a "known zero-day". That is a contradiction in terms. Either it is unknown, and exploited as a zero-day, or it is known, and therefore no longer a zero-day at all.

This particular exploit requires either physical or admin access to the target computer, which takes a lot of the edge off.

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 :(

For systems where there's a real fear of physical compromise, you'd think there would be more physical mitigations.

The crypto stuff is nice, but I feel like it's difficult to package in a way that non-technical audiences will understand it and not shoot their foot off somehow.

I feel like PCs where the storage can be pulled like a video game cartridge would reduce the threat surface, while avoiding a lot of the crypto risk (lost keys, broken TPMs)

If MSFT were acting carefully to avoid bugs, they wouldn't be abolishing the QA department and replacing it with Windows Insiders and Telemetry and Virtualization, and they wouldn't be releasing a bug every time they release a monthly patch.

Isn't it stupid that when MSFT sold Windows 11, they urged people to buy PCs with TPM 2.0 for improved security, but Windows 11 has vulnerabilities that cannot be easily addressed?

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.

> 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?

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.

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.

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)

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.

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.

Ha, sticking a rescue ISO on a partition is actually a nice touch, never thought of that.

> you may want to add a grubfmx64.efi in there, to be able to select entries more easily for rescue ops

I hate having to deal with bootloaders with a passion. But it could come in handy if my efi can't boot directly from the iso. It does have the option to browse local drives and boot random files, but I've never tried an iso.

Although my rescue iso is custom-made with archlive so that it supports zfs. I could probably just write it to some extra partition and boot it directly.

> my rescue iso is custom-made with archlive so that it supports zfs. I could probably just write it to some extra partition and boot it directly.

Interesting! Would you like to share it somewhere (or at least the build instrunctions?

It would be faster than a ubuntu live, which needs to start Gnome, while I often only need gdisk, dd, efibootmgr and zfs!

It's pretty basic, really. Follow the Arch Wiki guide to build an ISO and add the packages from the archzfs repo. One unrelated tip is to also bake your ssh pubkey in the ISO, it comes in handy.

https://wiki.archlinux.org/title/ZFS#Create_an_Archiso_image...

> 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.

No you are not, Linux and BSD fully replace firmware on boot. Plus BIOS boot is just a pass through to the OS and the OS does its thing.

This is for enterprise PC fleets... not home PCs. MS will auto enable in 2024.

> How will grandma/pa be able to understand these instructions.

To be completely honest I expect this to be more of an issue for my grandchildren and I expect them to come pestering me about all this.

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

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.

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?

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.

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.

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.

If I can fully erase it, that's what I'll do. Disabling it is a comprise from a weakened position.

> It won't boot Windows

You can sign the Windows bootmg efi files with your own keys if you want.

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_Firmware...

Do you have a detailed article about this? I am trying to set up something like you mentioned

The page seems to have changed since I've set this up, but this is what I've followed: https://wiki.archlinux.org/title/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.

Unfortunately, I am suspicious based on some recent circumstances that this bug is being exploited in the wild.

If you do run Windows, be sure to check that your TPM/SecureBoot devices are enabled, and that Core Isolation/Code Integrity (for example, Hypervisor Enforced Code Integrity) is enabled if possible. Unfortunately, this setting can sometimes cause driver incompatibilities and enabling it via the registry manually may be experimental/crashprone.

https://learn.microsoft.com/en-us/windows/security/threat-pr...

Network-based IDS helps a lot in this area -- something like pfSense with pfblocker-ng + Suricata. Unfortunately, there is also malware that can masquerade protocol/etc: https://www.cisa.gov/news-events/cybersecurity-advisories/aa...

I think people are overly quick to dismiss the effectiveness of IDS. Yes, rules often match symptoms/exploit instances rather than actual vulnerability semantics (though this has improved. But like a bike lock, even imperfect IDS gives you protection against opportunistic attacks that are pervasive for any system connected to the Internet.

The fact that IDS can respond without needing to validate a new software release means it can also very often outpace remediation through software updates.

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.

This. Maintaining a grub boot loader next to a windows one is nothing but pain.

The headline is sensationalist fake news, but I don't expect decency from journalism anymore.

The patch itself is finished and out, Microsoft themselves even provide instructions for turning everything on. Anyone who actually cares about this can follow the instructions, so this is a sensationalist nothingburger.

As the article states below, this secure boot vulnerability affects not only businesses but also consumers.

"Secure Boot has been enabled by default for over a decade on most Windows PCs sold by companies like Dell, Lenovo, HP, Acer, and others. PCs running Windows 11 must have it enabled to meet the software's system requirements."

Reply on news.ycombinator.com