Ventoy
Ventoy copied to clipboard
ventoy
Ventoy should only allow the execution of Secure Boot signed executables when Secure Boot is enabled
Currently, on x64 systems, Ventoy is able to run when Secure Boot is enabled, through the use of MokManager to enroll the certificate with which Ventoy's EFI executable is signed.
However, because no additional validation is performed after that, this leaves system wide open to malicious ISOs.
For instance, someone could produce a Windows installation ISO that contains a malicious /efi/boot/bootx64.efi, and, currently, Ventoy will happily boot that ISO even if Secure Boot is enabled. This completely defeats Secure Boot and should not happen, as the only EFI bootloader that should be whitelisted for Secure Boot should be Ventoy itself, and any other EFI bootloader should still be required to pass Secure Boot validation.
Therefore, Ventoy/Grub should be altered as follows:
- Detect if Secure Boot is enabled
- If Secure Boot is not enabled, proceed as normal.
- If Secure Boot is enabled, signature validation of any chain loaded
bootx64.efiis performed - If the signature validation fails (i.e. if the
bootx64.efiis either not signed, or signed with credentials that aren't enrolled in this machine's Secure Boot store, or signed with credentials enrolled but with a hash that is in the Secure Boot revocation DBX), an error should be returned to the user andbootx64.efishould not be launched.
Hopefully this shouldn't be too complex to add, though it may require some research, and modifying GRUB to do just that might require a lot of work.
I also hope that the people who are adamant about never disabling Secure Boot do realize that, as it stands, the current version of Ventoy leaves them about as exposed as if Secure Boot was disabled, which of course isn't too great... Thankfully, this can be fixed so that, even when using Ventoy, Secure Boot can continue to fulfill the purpose it was actually designed for.
I believe GRUB (at least v2.04 and previous versions if patched with Fedora patches) already work exactly as you've described. However, I'm not sure whether chainloading of shims are allowed, and how it would work if you try to load for example Ubuntu when you already have Fedora's shim loaded. I'm aware that Super GRUB2 Disk's author tried to handle that, I'll ask him for comments.
@ventoy used Super UEFIinSecureBoot Disk files to disable UEFI file policy, that's the easiest way, but not a 'proper' one. In a real use case, when you have several Linux distros (not all of which have Secure Boot support), several unsigned UEFI utilities, it's just easier to temporary disable Secure Boot with SUISBD method. However, I guess it should be possible to automatically enroll ALL needed keys to shim from grub module on the first boot (when the user enrolls my ENROLL_THIS_CERT_INTO_MOKMANAGER.crt) and handle unsigned efi binaries as a special case or just require to sign them with user-generated key?
I'll think about it and try to add it to ventoy.
If someone has physical access to a system and that system is enabled to boot from a USB drive, then all they need to do is boot to an OS such as Ubuntu or WindowsPE or WindowsToGo from that USB drive (these OS's are all signed and so will Secure boot). From the booted OS, they are then free to do whatever they want to the system. It is pointless to try to enforce Secure Boot from a USB drive. The only way to prevent misuse when booting from USB is to set a BIOS password (and perhaps a boot password), set the BIOS to not boot from USB and it won't hurt to also use an encrypted filesystem for the OS on the hard disk (bitlocker/LUKS).
If someone has physical access to a system then Secure Boot is useless period. In that case there's no difference in booting from USB or plugging in a SATA or NVMe drive with the same content as you'd put on USB (and we can debate about intrusion detection if you want).
The point of this issue is that people are under the impression that because Ventoy supports Secure Boot, they will get the same level of "security" booting Secure Boot compliant media through Ventoy as if they had booted that same media directly, which is indeed a fair expectation to have, since the whole point of boot media creation software is to have the converted media behave as close as possible as the original would.
Thus, on a system where Secure Boot is enabled, users should rightfully expect to be alerted if the EFI bootloader of an ISO booted through Ventoy is not Secure Boot signed or if its signature doesn't validate. However what currently happens is that people who do have Secure Boot enabled will currently not be alerted to these at all. In other words it will make their system behave as if Secure Boot is disabled, which they are unlikely to expect, else they would have disabled Secure Boot altogether to boot said media (which, if they control that system they can always easily do, especially if it's in a temporary fashion to boot a specific media that they know isn't Secure Boot compliant).
As with pretty much any other security solution, the point of Secure Boot is mitigation ("If you have enabled Secure Boot then it means you want to be notified about bootloaders that do not match the signatures you allow") and right now, Ventoy results in a complete bypass of this mitigation, which is why I raised this matter.
Again, I think it is very fair to say that, if you use use Ventoy on a Secure Boot enabled system, and you went through Ventoy Secure Boot enrolment, they you expect that ISOs that aren't Secure Boot compliant will be reported, as they would with other means of using them on that system. But, currently, that is not the case at all, which means that, independently of the merits of Secure Boot for this or that type of media (which is a completely different debate altogether), there is a breach of the security contract that the user expects to see enforced and therefore something that needs to be addressed.
@pbatard, if that's what what your concern, that could be easily fixed by deleting grubia32.efi and grubx64.efi in /EFI/BOOT, and renaming grubia32_real.efi ⇒ grubia32.efi, grubx64_real.efi ⇒ grubx64.efi.
This will disable validation policy override, making Secure Book work as desired: it will load only signed files (+ files signed with SHIM MOK key).
But it shouldn't be to the user to do that. It should be the default of Ventoy, which is the point of this issue.
If someone uses Ventoy with Secure Boot, then Ventoy should not green light UEFI bootloaders that don't comply with Secure Boot. If I am using Ventoy and I went the trouble of enrolling it for Secure Boot, I don't expect it to suddenly flag any unsigned or UEFI bootloader or bootloader with a broken signature, as bootable in a Secure Boot enabled environment. Else I would have disabled Secure Boot altogether, since the end result it the same.
That's actually very hard to do, and IMO is pointless in Ventoy case.
Linux distributives use Shim loader, each distro with it's own embedded certificate unique for each distro. Shim itself is signed with Microsoft key. Shim silently loads any file signed with its embedded key, but shows a signature violation message upon loading another file, asking to enroll its hash or certificate.
So, Fedora has shim that loads only Fedoras files. Ubuntu has shim which load only Ubuntu, etc.
As Ventoy itself is not signed with Microsoft key, it uses Shim from Fedora (or, more precisely, from Super UEFIinSecureBoot Disk). Say, we disabled validation policy circumvention and Secure Boot works as it should. The user has Ubuntu, Fedora and OpenSUSE ISOs which they want to load. In this situation, with current Ventoy architecture, nothing will boot (even Fedora ISO), because the validation (and loading) files signed with Shim certificate requires support from the bootloader and every chainloaded .efi file (it uses custom protocol, regular EFI functions can't be used. This seem to be disabled in Ventoy's custom GRUB). Ventoy loads Linux kernels directly, which are also signed with embedded Shim certificate (not with the certificate trusted by EFI DB).
Of course, there are ways to enable proper validation. For example, Ventoy can be modified to somehow chainload full chain of distros shim ⇒ grub ⇒ kernel, or custom validation functions could be made, which would, for example, validate and accept files signed with certificates in DB + a set of custom certificates (like ones embedded in distros' Shims), or even validate and automatically extract Shims embedded certificates and override EFI validation functions (as it's done currently to completely disable validation), but is this kind of complexity worth it for a USB boot utility which is implemented to be simple and convenient?
Can't say for others, but I made Super UEFIinSecureBoot Disk with that exact purpose: to bypass Secure Boot validation policy.
Most of modern computers come with Secure Boot enabled by default, which is a requirement for Windows 10 certification process. Although it could be disabled on all typical motherboards in UEFI setup menu, sometimes it's not easily possible e.g. due to UEFI setup password in a corporate laptop which the user don't know.
This disk, after being installed on a USB flash drive and booted from, effectively disables Secure Boot protection features and temporary allows to perform almost all actions with the PC as if Secure Boot is disabled. This could be useful for data recovery, OS re-installation, or just for booting from USB without thinking about additional steps.
I remember that @adrian15 tried to create a sets of fully trusted chainload chains to be used in Super GRUB2 Disk. @adrian15, could you tell us your progress on this?
That's actually very hard to do
It's a pain in the ass to do yes, but I wouldn't qualify it as very hard. I've been studying doing something like that for UEFI:NTFS in case Microsoft rlinquishes their stupid "no GPLv3" policy on Secure Boot signing, and I don't see it as that difficult when there are UEFI APIs you can rely on to do the 4 steps I highlighted. And that is the right thing to do.
and IMO is pointless in Ventoy case
Then congratulations: You have completely removed any benefits of using Secure Boot for any person who enrolled Ventoy on their Secure Boot computer. Because if I know you ever used Ventoy in a Secure Boot enabled environment, I can now run any malicious payload I want at the UEFI level, on your computer.
As Ventoy itself is not signed with Microsoft key
That doesn't mean that it cannot validate the booloaders that are being chainloaded. It's the job of Ventoy's custom GRUB to ensure that what is being chainloaded is Secure Boot compliant because that's what users will expect from a trustworthy boot application in a Secure Boot environment. If it fails to do that, then you have created a major security problem, no matter how you look at it.
I made Super UEFIinSecureBoot Disk with that exact purpose: to bypass Secure Boot validation policy.
Yes, anybody can make a UEFI bootloader that chain loads unsigned bootloaders with the express purpose of defeating Secure Boot. But unless it exploits a Secure Boot vulnerability or limitation (or you get cozy with the folks controlling shim keys), that bootloader should require to be enrolled to pass Secure Boot validation, in the same manner as Ventoy does it. And of course, people expect that if they run UEFIinSecureBoot or similar software, whose goal is explicitly stated as such, it will effectively remove Secure Boot. When enrolling Ventoy, they do not.
Or to put it more succinctly, when you give a copy of your house keys to someone, you don't expect them to leave the door open for everybody else to walk in...
I really fail to fathom how people here are disputing that if someone agrees to enroll Ventoy in a Secure Boot environment, it only means that they agree to trust the Ventoy application, and not that they grant it the right to just run whatever bootloader anybody will now be able to throw at their computer through Ventoy (which may very well be a malicious bootloader ran by someone who is not the owner of that computer but who knows or hopes that the user enrolled Ventoy).
In other words, that there might exist other software that might be used to force the door open is irrelevant. Else you might just as well make the argument that locking your house or car is pointless, and that nobody should ever bother about doing so, because a professional will have little trouble getting in anyway...
Therefore, unless Ventoy makes it very explicit that "By enrolling Ventoy for Secure Boot, you understand that you are also granting anyone with the capability of running non Secure Boot enabled boot loaders on your computer, including potential malicious ones that would otherwise have been detected by Secure Boot", I will maintain that there is a rather important security issue that needs to be addressed.
Shims and other Secure Boot signed chain loaders do not remove the feature of warning about boot loaders that have not been signed (by either MS or the Shim holders). But Ventoy currently does.
Don't get me wrong, I understand your concerns and support your position. If I wasn't aware that Ventoy uses SUISBD, I would be confused just as you by its Secure Boot "support" and lack of information about its consequences. The current Secure Boot implementation should be renamed from "Secure Boot support" to "Secure Boot circumvention/bypass", the documentation should state about its pros and cons, and Ventoy should probably ask to delete enrolled key (or at least include KeyTool, it's open-source).
I should also note that the key used in Ventoy is the same used in Super UEFIinSecureBoot Disk, my key.
Agreed. Secure Boot is tricky to deal with and can (rightfully) be seen as a major inconvenience instead of yet another usually desireable line of defence against malware (but by all means not a panacea).
And I also totally get where LogPanda/Ventoy is coming from when they decided to use your solution, because, from releasing boot media creation software, I can vouch to getting a lot of flak from users if your software happens to ask them to disable Secure Boot, even it's temporarily and after having validated that the content from the UEFI media came from trusted sources...
So any method that allows users to boot their media without having to explicitly disable Secure Boot can be seen as a nice thing to have... even if it comes at the price of reducing the overall security of one's computer.
Personally, I don't have much of an issue with Ventoy using the current approach as a stopgap solution, as long as it is agreed that this is only a stopgap, since it comes with a huge drawback, and that a better solution (validation of that the UEFI bootloaders chain loaded from GRUB pass Secure Boot validation when Secure Boot has been enabled by the user) needs to be implemented in the long run.
Oh and obviously, once that is done, Ventoy will need to make sure that it's not possible to run an older versions of it, in a Secure Boot environment where a newer version has been enrolled, as it would still defeat the whole thing. So that means that Ventoy will need to use a different key indeed.
@ValdikSS
Ventoy loads Linux kernels directly, which are also signed with embedded Shim certificate
Not exactly. Ventoy doesn't load the kernel directly inside the ISO file(e.g. Ubuntu.iso). Ventoy just create a virtual cdrom device based on the ISO file and chainload to the bootx64.efi/shim.efi inside the ISO file.
So as @pbatard said, the secure boot solution is a stopgap and that's why Ventoy is still at 1.0.XX. I will not release 1.1.0 until a relatively perfect secure boot solution.
Just some of my thoughts: Maybe I can get Ventoy's grub signed with MS key. Then Ventoy will load without issue if the secure boot is enabled in the BIOS. In this case, only these distros that bootx64.efi was signed with MS's key can be booted.(e.g. Fedora/Ubuntu/xxx). All other distros can not be booted. All the .efi files may not be booted. Does shim still needed in this case?
When install Ventoy, maybe an option for user to choose. Option1: Use current solution(Super UEFIinSecureBoot Disk), then user will be clearly told that, in this case, the secure boot will be by passed.
Option2: Use Ventoy's grub which is signed with MS key. Then user will be clearly told that, in this case only distros whose bootloader signed with valid key can be loaded.
Just some preliminary ideas. A lot of work to do. For example, how to get Ventoy's grub signed with MS key. How to make sure that only valid .efi file can be loaded.
Not exactly.
Yes, I already understood my mistake. I've made some tests this evening, it should be possible to make more-or-less proper Secure Boot support in Ventoy, but that would require modification of grub code to use shim protocol, and digital signatures for all Ventoy efi files, modules, etc.
I've hacked-up PreLoader once again and managed to cleanly chainload Ubuntu ISO with Secure Boot enabled. Will polish and publish the code later.
Yes. for grub modules, maybe I can pack all the modules into one grub.efi and for other efi files(e.g. ventoy_x64.efi/ventoy_util_x64.efi ...) , they do need digital signatures.
Is it valid for Ventoy to be able to run user scripts, inject user files into Linux/Windows ram disks, change .cfg files in 'secure' ISOs, etc. when the user Secure Boots via MokManager - even when booting signed efi files of Ubuntu or Windows? Will these functions in Ventoy be disabled if Secure Boot is detected? Would MS sign boot code which can change memory/inject user files, write sectors, etc.?
@steve6375
I think it's OK.
The injection is just like that I extract the ubuntu.iso and change/add some script and create an new ISO file.
This ISO file doesn't change the secure boot policy. All the .efi/kernel/drivers are not modified. So the new ISO file can be booted fine in a secure boot enviroment.
There are many kinds of WinPE. These WinPE have different user scripts inside the ISO files. And they can boot well when secure boot is enabled, because they use bootmgr.efi directly from Windows iso.
So all Ventoy's behavior doesn't change the secure boot policy. unsigned .efi file still can not be chainloaded. unsigned kernel still can not be booted.
Exactly. The point is that if a user whitelists Ventoy using MokManager, they are responsible for anything that they then subsequently run using Ventoy. They can choose to run a signed Ubuntu EFI file and Ventoy can change it's default function using scripts and file injection. Ventoy can boot any wim file and inject any user code into it. The user could choose to run a Microsoft Windows Install ISO downloaded from the MS servers and Ventoy could inject a malicious file into it as it boots. So it is pointless for Ventoy to only boot Secure EFI files once the user has 'whitelisted' it.
@steve6375 I think it's OK. The injection is just like that I extract the ubuntu.iso and change/add some script and create an new ISO file. This ISO file doesn't change the secure boot policy. All the .efi/kernel/drivers are not modified. So the new ISO file can be booted fine in a secure boot enviroment.
There are many kinds of WinPE. These WinPE have different user scripts inside the ISO files. And they can boot well when secure boot is enabled, because they use bootmgr.efi directly from Windows iso.
So all Ventoy's behavior doesn't change the secure boot policy. unsigned .efi file still can not be chainloaded. unsigned kernel still can not be booted.
Some commands in Ventoy grub can modify the contents of the ISO and must be disabled for users to use on their own under secure boot.
Exactly. The point is that if a user whitelists Ventoy using MokManager, they are responsible for anything that they then subsequently run using Ventoy. They can choose to run a signed Ubuntu EFI file and Ventoy can change it's default function using scripts and file injection. Ventoy can boot any wim file and inject any user code into it. The user could choose to run a Microsoft Windows Install ISO downloaded from the MS servers and Ventoy could inject a malicious file into it as it boots. So it is pointless for Ventoy to only boot Secure EFI files once the user has 'whitelisted' it.
We talk about secure boot, not secure system. When secure boot is enabled, only .efi/kernel/drivers need to be signed. All the userspace applications don't need to be signed. That is to say, a WinPE.iso or ubuntu.iso file can be booted fine with secure boot enabled(even no need for the user to whitelist them) but it may contain a malicious application in it. Preventing malicious programs is not the task of secure boot.
When user whitelist Venoy that means they trust Ventoy (e.g. they reviewed all the source code). But that not means they trust all the distros booted by Ventoy. Although a .efi file with valid signature is not equivalent to a trusted system.
@steve6375 I think it's OK. The injection is just like that I extract the ubuntu.iso and change/add some script and create an new ISO file. This ISO file doesn't change the secure boot policy. All the .efi/kernel/drivers are not modified. So the new ISO file can be booted fine in a secure boot enviroment. There are many kinds of WinPE. These WinPE have different user scripts inside the ISO files. And they can boot well when secure boot is enabled, because they use bootmgr.efi directly from Windows iso. So all Ventoy's behavior doesn't change the secure boot policy. unsigned .efi file still can not be chainloaded. unsigned kernel still can not be booted.
Some commands in Ventoy grub can modify the contents of the ISO and must be disabled for users to use on their own under secure boot.
I think it's ok as long as they don't break the secure boot policy.
Maybe I can get Ventoy's grub signed with MS key.
You can't. Point 4 from Microsoft's official Secure Boot signing requirements states:
Code submitted for UEFI signing must not be subject to GPLv3 or any license that purports to give someone the right to demand authorization keys to be able to install modified forms of the code on a device. Code that is subject to such a license that has already been signed might have that signature revoked. For example, GRUB 2 is licensed under GPLv3 and will not be signed.
They explicitly mention GRUB.
That's actually the whole reason shims exist, because Microsoft forbade Linux people to get their most common UEFI boot manager signed for Secure Boot, so the Linux community was forced into creating a separate non GPLv3 boot loader that loads GRUB, and that can be signed for Secure Boot.
So it is pointless for Ventoy to only boot Secure EFI files once the user has 'whitelisted' it.
That's not at all how I see it (and from what I read above also not @ventoy sees it).
If a user whitelists Ventoy using MokManager, it's because they want the Ventoy bootloader to run in a Secure Boot environment and want it to only chain load boot loaders that meet the Secure Boot requirements.
The idea that Ventoy users "should know what they are getting into" or that "it's pointless to check UEFI bootloaders for Secure Boot" once Ventoy has been enrolled is disingenuous at best. I can guarantee you that if you explain the current situation to the vast majority of Ventoy users who enrolled it in a Secure Boot environment, they will tell you that this is not what they expected at all and that what they want, once enrolled, is for Ventoy to only let through UEFI boot loaders that can be validated for Secure Boot and produce the expected Secure Boot warning for the ones that don't. That's because, if they did want to boot non Secure Boot enabled ones, they would disable Secure Boot themselves.
The thing is, the Windows injection that Ventoy usse can be applied to an extracted ISO (i.e. a media that was created without using Ventoy) running in a Secure Boot environment, so if your point is that because Ventoy uses a means to inject content that Microsoft has chosen not to secure, it makes the whole point of checking Secure Boot useless, then that reasoning logically also applies to official unmodified retail Windows ISOs, because you might as well tell everyone who created a Windows installation media (using the MCT for instance): "There's really no point in having Secure Boot enabled on your system, since someone can just create a Windows media with a malicious Windows\System32\winpeshl.exe payload to compromise your system at early boottime anyway"...
Again, if someone has Secure Boot enabled, and did not whitelist a third party UEFI bootloader themselves, then they will expect the system to warn them in that third party bootloader fails Secure Boot validation, regardless of whether they did enrol a bootloader that chain loaded that third party bootloader.
It's that simple. Really.
You can't. Point 4 from Microsoft's official Secure Boot signing requirements states:
Yes. So maybe Ventoy also need a shim as fedora/ubuntu does.
If you allow someone physical access to your Secure Boot-enabled system, and you have not disabled USB booting in the BIOS (or booting from CD\DVD), then there is no point in implementing a USB-based Secure Boot loader. If Ventoy was intended to be used from an internal hard disk, I would agree with you, but Ventoy is a USB-based multiboot solution and therefore the user must have physical access to the system, so it is the users responsibility to be careful about what he inserts into that USB port. Maybe we should just ask the user 'This file is not signed by Microsoft for 'Secure Boot' - do you still wish to boot from it?' and leave it up to the user.
So maybe Ventoy also need a shim as fedora/ubuntu does.
Yeah... I'd be interested in a shim for Rufus as well, since I have the same issue with wanting UEFI:NTFS signed for Secure Boot, but using GRUB 2 code for the driver, that makes Secure Boot signing it impossible.
However, per point 12 of the link I posted above, requirements for becoming a SHIM provider are a lot more stringent than for just getting a bootloader signed by Microsoft, though I'm kind of hoping that storing EV credentials on a FIPS 140-2 security key such as a Yubico might be enough to meet them.
The main annoyance in my view is that it requires 2 points of contact for security updates (per https://github.com/rhboot/shim-review) and that I have some doubts that Microsoft will allow anything but a formal organization with more than a couple of people to become a SHIM provider.
However, considering that in the case of Ventoy, you are basically going to chain load GRUB 2, and that most of the SHIMs have been designed to handle precisely that, it might be easier to get Ventoy accepted as a shim payload.
then there is no point in implementing a USB-based Secure Boot loader.
Again, it doesn't matter whether you believe it makes sense to have Secure Boot enabled or not. What matters is what users perceive and expect. And, unless you're going to stand behind every single Ventoy user to explain why you think it shouldn't matter that Ventoy will let any unsigned bootloader through, that's just not going to fly. Users enabled Secure Boot to be warned if a boot loader fails Secure Boot validation, regardless of where that bootloader is executed from. And we've already been over whether USB should be treated differently than internal SATA or NVMe (which, in your opinion it should, and which in mine, and I will assert the majority of people who enable Secure Boot, it shouldn't).
Maybe we should just ask the user 'This file is not signed by Microsoft for 'Secure Boot' - do you still wish to boot from it?' and leave it up to the user.
Well, that's pretty much exactly what I suggested in points 1-4 from the original post, with point 4 altered from "an error should be returned to the user and bootx64.efi should not be launched" to "an error should be returned to the user who can then decide if they still want to launch bootx64.efi".
I have absolutely no problem with letting the user choose if they want to run a bootloader that failed Secure Boot validation, and I think this might be the better way to do it indeed. The main issue is that users should at least get some warning that a bootloader failed SB validation when SB is enabled, instead of just letting everything go through.
This file is not signed by Microsoft for 'Secure Boot' - do you still wish to boot from it?
Yes. The user should be notified when booting an unsigned efi file. But even the user answer "YES, I don't care, just boot it." we have no ability to boot it unless we disable the secure boot because it is not signed.
Yeah, I think UEFI LoadImage()/StartImage(), which is what you'd call to chain load the UEFI bootloader, are set to validate the loaded image for Secure Boot and not launch it for unsigned/broken images, if Secure Boot is enabled (but I admit I haven't formally validated that).
However, I would say that, if you are already running "arbritrary" code in UEFI mode to display a user message, while Secure Boot is enabled, then you should be able to craft your own LoadImage()/StartImage() that doesn't go through SB validation (by copying the LoadImage()/StartImage() code from the EDK2 and removing the validation part). So booting an unsigned file at the user request should still be achievable, though it might require a lot of extra work to do so...
I would say that it probably makes sense to first see what LoadImage()/StartImage() let through in an SB enabled environment (provided that this is what Ventoy/GRUB uses behind the scenes, which I'm not too sure about), and then decide if it's worth/possible to let users choose to run unsigned bootloaders.
That's theoretically feasible but is clearly banned by the shim/MS. So I think that also means Ventoy will definitely impossible to be a shim provider. The only way to make Ventoy boot in secure boot is to enroll the key.
If someone has physical access to a system then Secure Boot is useless period. In that case there's no difference in booting from USB or plugging in a SATA or NVMe drive with the same content as you'd put on USB (and we can debate about intrusion detection if you want).
@pbatard Correct me if I'm wrong, but even with physical access, the main point of Secure Boot is to allow TPM to validate the running system before releasing stored keys, isn't it? So even when someone physically unplugs my SSD and installs a malicious bootloader/OS to it, it won't be able to decrypt the main OS partition. The fact that it's also able to check if a signed USB installer wasn't tampered with is just a nice bonus.
the main point of Secure Boot is to allow TPM to validate the running system before releasing stored keys, isn't it?
No. The main point of Secure Boot is to prevent (or at least warn about) the execution of bootloaders that have not been vetted by Microsoft or one of the third parties that Microsoft signed a shim for (such as Red Hat).
What you want is for users to be alerted if someone picked a Linux or Microsoft media, and the UEFI bootloader was altered from the original. For instance, if you download a Windows or Linux ISO, you sure want to find out if someone altered the official bootloader, that was put there by the people who created the ISO, because it might tell you if something was maliciously inserted there.
Now, that one can currently break the trust chain somewhere down the line, by inserting a malicious program at the first level where the trust stops being validated, which, incidentally, as a method (since I am NOT calling Ventoy malicious here) is very similar to what Ventoy is doing for Windows boot, is irrelevant to the matter, because one can very much conceive an OS that is being secured all the way (and, once again, if Microsoft were to start doing just that, then that would most likely mark the end of being able to use Ventoy with Windows ISOs since it would no longer be able to inject an executable that isn't signed by Microsoft as part of the boot process) and that validates the signature of every single binary it runs along the way... which means that the trust chain needs to start somewhere and (as far as user providable binaries are concerned) that trust chain starts with Secure Boot. I suspect that, even as we are not there yet, this is something that we're eventually going to see (but most likely as a choice for the user to install the fully secured or partially secured version of the OS), culminating in OSes where every single binary that runs needs to be signed, and for the certificates those binaries are signed with to be in the chain of trust of OS.
Thus, being able to check that an installer or boot loader wasn't tampered with is not a "nice bonus" but is something that must be enforced always in a Secure Boot enabled environment, regardless of the type of media you are booting from, because Secure Boot is very much designed to help users ensure that, when they install an OS, and provided that OS has a chain of trust that extends all the way, any alteration of any of the binary code that the OS executes, be it as part of the installation or when the OS is running, will be detected and reported to the user and prevent the altered binary code to run. And if you somehow let bootloaders that shouldn't be trusted through, such as unsigned ones, then it means your whole chain of trust is utterly broken, because there simply cannot even exist a special case for "USB" vs "something else".
And, unfortunately, with Ventoy as it stands, this whole trust mechanism is indeed broken, because you can take an official Windows installation ISO, insert a super malicious UEFI bootloader (that performs a Windows installation while also installing malware) and, even if users have Secure Boot enabled (and added Ventoy in Mok manager), they will not be alerted at all that they are running a malicious bootloader, whereas this is the whole point of Secure Boot!
Again, detecting malicious bootloaders, from any media, is not a bonus. It's what Secure Boot is designed to do on account of being a trust chain mechanism that, when enabled, MUST alert if trust is broken. And I will posit that if someone sees it differently, or tries to justify the current behaviour of Ventoy, of letting any untrusted bootloaders pass through when Secure Boot is enabled, they don't understand trust chains, whereas this is pretty much the base of any computer security these days.
For instance, if you produce digitally signed software for Windows, to ensure that your users can validate that when they run an application, they can tell with certainty whether it comes from you or not, you really don't want someone to install software on the user computer that will suddenly make applications that weren't signed by you look as if they were signed by you. Yet, that is technically what Ventoy does if you enrol it for Secure Boot, as it makes it look like any bootloader, that wasn't signed by Microsoft, was signed by Microsoft.
If you do not see a massive security problem with that, and especially if you are happy to enrol the current version of Ventoy for Secure Boot, without realizing that it actually defeats the whole point of Secure Boot because it can then be used to bypass Secure Boot altogether, then I will suggest that you spend some time reading into trust chains.
@pbatard Sorry, I should have explained my position clearer - I fully agree that the Secure Boot bypass Ventoy uses is not secure, and I'm not using Ventoy exactly because of it. I was just objecting to your claim that Secure Boot is useless when someone has physical access to the device, which I don't think is true, as it is still (afaik) required for TPM-based encryption to work correctly.
Nevertheless, thanks for the explanation, it cleared up some things for me around the threat model of Secure Boot.
TPM encryption has historically been independent of Secure Boot. You were able to use TPM for disk encryption long before Secure Boot, and rightfully so, since the process of storing and using data encryption keys is completely different from the process of storing and using trust chain keys to validate binary executables (being able to decrypt something is very different from being able to trust something).
You can have BIOS with TPM and disk encryption and, provided your hardware manufacturer implements anti tampering protection to ensure that the TPM is not sharing data it shouldn't share with parts of the system that should not be trusted, it should be no less secure than TPM-based encryption on a Secure Boot enabled system.
So, Secure Boot is not required for TPM-based encryption to work correctly.
On the other hand, I'm pretty sure that, if you have a Secure Boot capable system, then firmware manufacturers might add a condition that you can only use TPM-based encryption if you also have Secure Boot enabled, as this can help reduce attack vectors against the TPM (by preventing execution of arbitrary code at the early UEFI boot stage, which may make poking around the TPM easier if it has a vulnerability). So, yeah, it's the same as a safe manufacturer, on seeing that you have a room with extra security (e.g. access with key cards) making sure that your safe does get installed there, so that it should give you an extra chance to detect ill intentioned people trying to access its content. But, whereas this is good security practice, that is not a requirement.
Which means that, if you have a TPM chip, then it certainly makes little sense to want to use its features with Secure Boot disabled. And it's possible that the UEFI specs went as far as specifying that specific aspects of the platform security, such as disk encryption through TPM, should only be available if Secure Boot is enabled. But, even as I don't actually support the idea that Secure Boot is useless if someone has physical access to the device (that was mostly Steve positing this as a means to justify that not being able to detect Secure Boot breaches on USB media isn't that big a deal), I do believe there currently still exist a bit too many ways to ensure that you can compromise a machine, if you have access to said machine. Heck, in the absolute, if you have the means (And please note here that I'm not saying that any regular Joe, who doesn't already have access to the whole gammut of NSA resources, can do it), you can replace the CPU with your own custom FPGA, and it's pretty much game over, as, apart from easy to defeat matters such as serial number check, your TPM will be designed to work with anything that remotely looks like a CPU, and if you communicate with it like a CPU would, it'll happily help you access whatever data you request... such as decrypted disk content.
So, yeah, if you have access to to the hardware, then Secure Boot, TPM or whatever security measure you currently have on consumer-grade products, is pretty much useless because, as long as you can swap hardware components around, or even touch the hardware (to glitch the RAM for instance), then unless the TPM comes with an X-Ray machine that can scan and compare hardware components, you're going to have a very hard time plugging all the many holes through which a dedicated attacker can gain access to your data.
Which brings us nicely to what this is all about: Mitigation.
All of these security things are there to mitigate risks. They can't eliminate them totally, but they can provide an additional level of protection. Which is why you want to have as many of these enabled in parallel when they exist (such as TPM + Secure Boot, i.e. your point) and you also want them to actually do their designated job, including letting you know, if you have Secure Boot enabled, when some third party UEFI boot loader didn't pass Secure Boot validation, even if that boot loader will only ever be run from someone who has to have physical access to your computer in the first place.
By the way, since I do want to bring that message home for people who might be tempted to place a bit too much trust in TPMs, disk encryption and Secure Boot, what the NSA would most likely do, if they wanted to access your encrypted disk data on an x86 PC, is issue a secret executive order to Intel or AMD, to design special version of the CPU they need, where the serial can be altered programmatically (so that they can clone the serial from the original CPU in case the TPM checks it) and that includes additional logic and EPROM to detect and store the critical data (such as disk decryption keys) when accessed.
Then the process of reading your "TPM-secured" disk becomes as easy as:
- When the user is away, clone the encrypted disk and replace their existing CPU with the slightly altered model (after making sure to clone the CPU serial)
- Let the user access their computer (fat chance they're going to remove the heatsink and thermal paste to see if their CPU was changed, especially if, as far as they are concerned, no change as occurred and both the computer appearance and behaviour are indistinguishable from usual).
- When the user is away again, remove your TPM-exfiltration CPU and place the old one back. And for good measure, clone that encrypted disk again.
- Decrypt the cloned disk data at your leisure by using the data that was stored in your "altered" CPU...
User awareness that their encrypted data was read: Nil.
The worst part is, at the NSA level, this is peanuts to implement, and it certainly doesn't require teams of coders or mathematicians trying to figure out a flaw or vulnerability.
@pbatard
You were able to use TPM for disk encryption long before Secure Boot, and rightfully so, since the process of storing and using data encryption keys is completely different from the process of storing and using trust chain keys to validate binary executables (being able to decrypt something is very different from being able to trust something).
Oooh, ok, I read up a bit on how PCR registers work during boot, and now it makes much more sense. I thought that Secure Boot chain of trust is reused for TPM key sealing, but thinking about it more, that wouldn't really work. Happy to be proven wrong, I learned quite a bit from your messages. Thanks a lot.
@pbatard and others
I've made another patched preloader with Secure Boot support. It implements the following features:
- Discovery and usage of shim protocol of loaded shim binary for global UEFI validation functions (validation policy override with shim verification)
- Shim protocol unregistration of loaded shim binary (to prevent confusion among shims of multiple vendors and registration of multiple protocols which are handled by different chainloaded shims)
- Optional custom shim protocol registration (not included in this build, creates issues).
This preloader allows to use Ventoy with proper Secure Boot verification. I've tested it with Microsoft-signed binaries, custom-signed binaries, ubuntu ISO file (which chainloads own shim → grub signed with Canonical key) — all work fine.
Please thoroughly test the archive and give your feedback, what works and what don't. If everything is fine, I'll prepare the repo, prettify the code and write detailed compilation and usage instructions, as well as help @ventoy with integration.
preloader-for-ventoy-prerelease.zip
I'm afraid I'm very busy with other projects, so I haven't had a chance. I would also like to point out that I reported the issue as a general remark to help with Ventoy development, after looking at the manner in which Ventoy was addressing the Secure Boot problem (and finding an issue there), rather than as an actual Ventoy user.
I'm hoping other people can test and report because it will most likely be a few weeks before this can make it to the top of my priority list...
@ventoy, are you interested in a proper implementation of Secure Boot support? Please test and tell your opinion.
@ValdikSS
Sorry for the late test.
I installed ventoy-1.0.32 and replace the .efi files.
I test it in a VirtualMachine (VMWare with secure boot enabled).
Firstly, I run into the MOKManager screen and enroll the testkey-ventoy.der and reboot.
But this time I get The firmware encountered an unexpected exception. The virtual machine cannot boot.
I will test it in a realmachine later.
PS: It works fine with original ventoy release (use UEFIinSecureBoot) when Secure boot is enabled.
Besides, I'm considering that: Maybe I can provide 2 options for the user in the install program or by plugin. Option 1: Completly by pass the secure boot like the current release. Option 2: Only boot .efi file with valid signature.
When the user select option 1. Do I need a custom shim protocol?
@ventoy, I've tested it only in qemu and it worked fine. I'll test it on a real hardware a bit later.
Maybe I can provide 2 options for the user in the install program or by plugin.
That would be ideal.
When the user select option 1. Do I need a custom shim protocol?
No, you don't need to implement anything new in Ventoy.
@ventoy, try this archive, for 1.0.40.
preloader-for-ventoy-prerelease-1.0.40.zip There are two bugs in Ventoy:
- Minor one: when you try to start unsigned .efi executable, error message is shown for a very brief time and quickly disappears.
- Unsigned bootloader Linux ISOs or ISOs without UEFI support does not boot with Secure Boot enabled. I'm not sure whether Ventoy should try to boot Linux kernel without any verification in this case (@pbatard, what do you think?)
Unsigned bootloader Linux ISOs or ISOs without UEFI support does not boot with Secure Boot enabled.
This is definitely what you want. When Secure Boot is enabled, BIOS boot (CSM) should not work at all, since it would completely defeat the purpose of only allowing signed executables to boot. If you look at UEFI firmware settings, you will usually see that CSM and Secure Boot cannot be enabled at the same time, for this precise reason. And of course, by the same logic, anything unsigned should not boot when Secure Boot is active.
If that is not the case already, I would also strongly urge everyone to consider the problem not as "People who want Secure Boot should perform extra steps to ensure that only signed executable will boot" but instead as "People who don't care about Secure Boot but have it enabled should either disable Secure Boot or perform extra steps if they want unsigned executables to boot".
In other words, Option 2 should be the default if Secure Boot is enabled, and users who want Secure Boot should be encouraged to go with that option, with a clear indication that Option 1 will place their system at risk from malicious software and, unless Ventoy produces a big red warning any time an unsigned bootloader is encountered, is sessentially the same as having Secure Boot disabled...
I am mentioning this because I have some slight concern at seeing what should be the default option, and what users should be encouraged to pick when a lot of them are adamant about leaving Secure Boot enabled, relegated to number 2... If anyone has Secure Boot enabled, there should be no scenario where an unsigned bootloader gets executed without at least a big red warning, even if the user indicated that they were okay with that. That's because the real issue in this case, is that the user clearly has no clue what they want, since, if they enabled Secure Boot to prevent the execution of unsigned bootloaders, yet later tell Ventoy that it should allow the execution of unsigned bootloaders, they want two fundamentally incompatible things...
This is definitely what you want.
I'm not talking about CSM. Ventoy can detect GRUB inside ISO file, parse its configuration file and load its boot elements directly, with "linux" GRUB kernel loading command.
Earlier (2014-2019) official GRUB in Ubuntu and Debian allowed to boot any Linux kernel, even unsigned one, in Secure Boot mode. This was not considered Secure Boot violation as ExitBootServices() was called prior to booting the kernel. Only in 2019 the signature validation was enforced. So, this is debatable.
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532
@ValdikSS Thanks, I will test it as soon as possible. For the two bugs.
- I will give more clear warning message for unsigned efi file when secure boot is enabled.
- Currently when boot the ISO file failed as a Virtual CDROM, Ventoy will try to parse the grub configuration file inside the ISO file and try to boot it direclty with
linuxinitrdcommand. But this feature will definitely be disabled when secure boot is enabled.
@pbatard Option 2 will be the default option. I'm considering two ways for user to select option 1.
-
In the install program
Ventoy2Disk.exe. Currently there is only aSecure boot supportoption for check. I can 3 options and option 3 is the default. Option 1: doesn't support secure boot at all Option 2: bypass secure boot Option 3: only run .efi file with valid signature. -
Remain what in the install program
Ventoy2Disk.exe. When user check theSecure boot supportoption thenonly run .efi file with valid signatureis select. I can provide an option in ventoy.json for user who want to bypass secure boot.
For these who select to bypass secure boot. Do I still need to display a warning message? Won't it be annoying?
@ValdikSS, I'm not seeing much being debated, when the link you point to appears to indicate that pretty much everybody is in agreement that loading unsigned kernels from GRUB, in a Secure Boot environment, is a bug (hence why it was reported as such).
Just like what is the case with Ventoy, I don't have much of an issue with having some leeway, on account that implementing proper signature validation requires some effort, during which unsigned bootloaders may be accepted, so as not inconvenience users too much. But, just like GRUB, I assert that this matter needs to be treated as a bug that warrants fixing, which is the reason I created this issue in the first place. And IMO, anything that attempts to push the idea that, maybe, allowing silent boot of unsigned bootloaders is not that bad, is actually doing a major disservice to users, as it does weaken the security of their system and, if this is really what a user wants, they can and should disable Secure Boot.
Again, the major problem I see with this fine discussion is that everybody appears to be tiptoeing around the fact that some users have no clue what Secure Boot is intended for (only that, because it says "Secure" they don't want to turn it off), and, rather than trying to educate them about that, we're trying to find ways to keep them "feeling safe" when the choices they might make would leave their system anything but.
@ventoy
Option 2 will be the default option.
Good.
I can provide an option in ventoy.json for user who want to bypass secure boot.
That would be my preference, because someone who wants to bypass Secure Boot indiscriminately, without disabling Secure Boot altogether, should have a clue what they are doing, and the problem with presenting options as a dialog is that you end up with tutorials that advise users to pick the less secure option, because whoever wrote happened to find the other choices inconvenient without giving much thought about the end result. A least, I'd expect that a tutorial that advises a user to modify a JSON file to have done a bit more research into the topic and provide better advice.
But of course, it's your choice to pick what you think is best for your users and the above is just one opinion on the matter.
For these who select to bypass secure boot. Do I still need to display a warning message?
I would assert that, when Secure Boot is enabled, every single time an unsigned bootloader is loaded, a warning message should be displayed.
Won't it be annoying?
That is the point. If a user is booting a lot of unsigned bootloaders with Secure Boot enabled, they clearly should disable Secure Boot in their settings, because, for what they are doing, it is pretty much pointless.
On the other hand, the expectation is that most users would only get the warning very occasionally, and you definitely want to bring to their attention that they might want to be careful about the current bootloader they are trying to boot, in case they haven't paid that much attention to where they got their image...
@ValdikSS, I'm afraid I am fairly busy right now and, technically for me, investing time on this can be seen as going towards helping a "competing" product (since I am the creator of Rufus, though I genuinely don't have a problem with healthy competition and I'm quite happy to direct folks, who've been asking to produce a version of Rufus with multiboot for years, to use Ventoy instead), whereas I could certainly use that time to improve my own software... 😉
I'll see if I can find some time in the next two weeks to play with your solution, but don't hold your breath.
@ventoy Now Rufus has achieved support for secure boot as now NTFS:UEFI Driver is signed for secure boot by Microsoft. So, Ventoy can also adopt that driver and support secure boot officially.
@pbatard I hope there will be no issues in this adoption. Will there be any?
Now Rufus has achieved support for secure boot as now NTFS:UEFI Driver is signed for secure boot by Microsoft.
Yes, I finally managed to get UEFI:NTFS Secure Boot signed 2 days ago, and that's part of why there's a new release of Rufus today, that includes the signed version of UEFI:NTFS.
It was actually quite the struggle to get to that stage (expensive too!) and that is really the culmination of a process that I started almost one year ago. As a matter fact, provided Microsoft didn't dismiss it on technical or legal grounds, I was really planning to UEFI:NTFS Secure Boot signed long before the release of Windows 11, yet here we are... So this process has still left a very sour taste in my mouth, because it's been nothing but unexpected hurdle after unexpected hurdle (and that's only a couple of them)...
So, Ventoy can also adopt that driver and support secure boot officially.
I'm not sure how Ventoy can make use of that boot process, because, in a Secure Boot enabled environment, all UEFI:NTFS accomplishes is that it allows you to chain load a Secure Boot signed UEFI boot loader from an NTFS partition, and that's it.
So I don't really see how that could be used to solve the specific problem we are being faced with here, because, however you plan to use UEFI:NTFS when Secure Boot is enabled, your target (be it Ventoy or something else) must be Secure Boot signed.
Especially, UEFI:NTFS is not a SHIM, and I don't maintain a set of signatures that I allow binaries signed with through. If that was the case, I would most likely sign Ventoy for my SHIM (provided it doesn't let through unsigned bootloaders when Secure Boot is enabled, which is the precise issue we are trying to solve) since, even if it's supposed to be a competitor of Rufus, I think it's a very nice solution and I'm always more than happy to direct people who would like to have a multiboot version of Rufus to use Ventoy instead. 😉
But, UEFI:NTFS is not a SHIM and that's actually the reason why it could be signed by Microsoft (once I switched the bootloader license from GPLv3+ to GPLv2+ and rewrote a UEFI driver derived from GPLv2+ code, which I am definitely not happy at all about), because, in a Secure Boot enabled environment, it can not be used to chain load anything that isn't itself Secure Boot signed. And unfortunately, because Ventoy is derived from GRUB 2.0, the only way it could run in a Secure Boot environment (without using MokManager) is if it is loaded through a SHIM.
Now, if Microsoft finally relinquished their abusive policy about not accepting GPLv3 code for Secure Boot signing and Ventoy was updated not to allow unsigned bootloaders when Secure Boot is enabled (i.e. if this issue was addressed), it could probably be Secure Boot signed, in the same manner as UEFI:NTFS was itself Secure Boot signed. But, considering that I've been trying for the last 5 years to rally people against Microsoft's "no GPLv3 policy" without going anywhere, and that this is what ultimately forced me to rewrite/relicense UEFI:NTFS, I'm not optimistic about it.
And, for any of this to work, Ventoy would still need to independently solve the problem of allowing unsigned bootloaders pass through when Secure Boot is enabled...
@ventoy Any progress towards proper secure boot support without using mokmanager?
I remember that @adrian15 tried to create a sets of fully trusted chainload chains to be used in Super GRUB2 Disk. @adrian15, could you tell us your progress on this?
I am just resuming my work on it. Expect working results in 3 months maximum. I still don't know why it shouldn't work even if it's complex.
