OP/bug finder here with some clarifying information. It's a common misconception that this issue can only be abused if you use HTTP boot. That is not the case at all, otherwise it wouldn't be Critical. This bug can be abused locally (privileged malware can overwrite the EFI partition), from an adjacent network if PXE boot is enabled (w/ MiTM), or remotely if HTTP boot is used (w/ MiTM).
More details on these scenarios:
1. A remote attacker with no privileges in a man-in-the-middle (MitM) position could leverage the issue against a victim machine that uses HTTP boot. No direct access to the victim machine is required.
2. A remote attacker with privileges and code execution on the victim machine could leverage the issue to bypass Secure Boot, even if the victim does not already use HTTP boot (as long as firmware has HTTP support). How? Several ways:
- An attacker can edit the boot order variable to specify a controlled attacker server.
- An attacker can chain shim->GRUB2->shim (via HTTP). For this technique, an attacker would overwrite the boot loader in the EFI partition to a legitimate shim and GRUB2 image. The attacker would create a grub.cfg that chainloads a new shim via HTTP. This is possible because GRUB2's device syntax allows you to specify any supported device, including HTTP (if available).
3. An adjacent attacker with no privileges in a man-in-the-middle (MitM) position could leverage the issue against a victim machine that uses PXE boot. PXE is separate from HTTP boot, but similar to the local vector, an attacker can chain together shim (via PXE)->GRUB2 (via PXE)->shim (via HTTP).
Yes, if the attacker can edit the the victim machine's EFI vars or the contents of its ESP, then they can make the victim machine use HTTP boot even if the victim machine didn't use HTTP boot originally. However at that point they can also wreak more havoc without involving HTTP boot.
For the case where the default configuration has been set up to just chainload grub (ie what distros use shim for), and where an attacker editing EFI vars / ESP is not in the threat model, there is no concern. Yes that is just "It's not a concern because you defined it to not be." but that is the reality for most users of Secure Boot on Linux.
Also note that the reason I wrote that paragraph is because the HN submission was originally submitted with a title along the lines of "Every install of shim is affected".
> Yes, if the attacker can edit the the victim machine's EFI vars or the contents of its ESP, then they can make the victim machine use HTTP boot even if the victim machine didn't use HTTP boot originally. However at that point they can also wreak more havoc without involving HTTP boot.
How? The whole point of secure boot is that an attacker with even that level of access can't boot the machine in an authenticated way (and e.g. make the disk encryption key available).
Someone with enough privileged access to write to the ESP (ie root) can also add their own MOK to the ESP that the user might blindly accept next time they boot. Especially if they time it for when there is a legitimate new MOK in the ESP waiting to be accepted on next boot, so that the user is predisposed to accepting a new key.
They can also replace shim with other binaries with other vulnerabilities that were signed by the MS key in the past, in case DBX hasn't been updated with their hashes.
>The whole point of secure boot is that an attacker with even that level of access can't boot the machine in an authenticated way (and e.g. make the disk encryption key available).
Someone with enough privileged access to write to the ESP (ie root) can also just exfiltrate your disk contents at that point.
> Someone with enough privileged access to write to the ESP (ie root) can also add their own MOK to the ESP that the user might blindly accept next time they boot. Especially if they time it for when there is a legitimate new MOK in the ESP waiting to be accepted on next boot, so that the user is predisposed to accepting a new key.
> They can also replace shim with other binaries with other vulnerabilities that were signed by the MS key in the past, in case DBX hasn't been updated with their hashes.
Neither of those sounds like a sure thing. The first relies on the user not checking the key, and is exposing the attacker to a lot of risk if they do. The second relies on DBX not being updated, for which the remedy is "don't do that".
> Someone with enough privileged access to write to the ESP (ie root) can also just exfiltrate your disk contents at that point.
The idea is that your main data partition is encrypted with a key held in a secure enclave and can only be retrieved after a secure boot. (Or, y'know, any of the other things people would use secure boot for). Your boot partition has to be unencrypted so you can boot from it, but there's no sensitive data on there, and an attacker with write access can't "rootkit" it because if they replace the bootloader with a different one then it will be unsigned and break the chain of trust. Again if this stuff didn't work then there would be no point in secure boot at all.
>The second relies on DBX not being updated, for which the remedy is "don't do that".
Not updating DBX is the default state. Updating it is what requires effort.
How many devices actually have up-to-date DBX? I know I mentioned LVFS in my first comment, but I have to wonder how many Linux devices with SB enabled actually use it. The ones that don't will not have updated their DBX since they were manufactured.
>The idea is that your main data partition is encrypted with a key held in a secure enclave [...]
You're missing the point. An attacker that can write to the ESP is root on the live system right now. It can exfiltrate the contents of `/` right now. Or if it can't exfiltrate right now, it can install an OS service to do that on future boots.
If the boot partition isn't encrypted, doesn't this mean an attacker with physical access to the machine can remove the drive, plug it into their own machine, overwrite the boot partition, then restore the drive back in the original machine? In that scenario they don't have access to the unencrypted root filesystem.
You can set up 'measured boot' so the TPM will only 'unseal' the disk encryption password if you're running a certain version of your BIOS, a certain set of Machine Owner Keys, a certain version of shim, a certain kernel, a certain kernel command line and so on.
Very few normal users do this because it's a great deal of effort/risk for very modest security improvements. But the option is present - it's sometimes used by big corporations making TiVo-style products to lock out the owners from messing with the hard disk in the manner you've described.
> Not updating DBX is the default state. Updating it is what requires effort.
Up to a point, but that's true for almost everything in software. Not updating your OS etc. is the default state, and if it's not up to date it will be full of holes. That's life.
> You're missing the point. An attacker that can write to the ESP is root on the live system right now. It can exfiltrate the contents of `/` right now. Or if it can't exfiltrate right now, it can install an OS service to do that on future boots.
If they have root on the live system then they don't need to mess around attacking secure boot at all. The point is "evil maid" style attacks where someone messes with the boot partition (and/or firmware) by booting off another device. Again, this is the whole point of Secure Boot; if you don't care about that kind of scenario then why would you ever be using secure boot at all?
Author here. Yes simply editing my hosts file would have been much easier. The reason I went the longer approach of setting up the payload on a remote web server was because there is the concept of security zones in Internet Explorer. Visiting localhost in Internet Explorer gets treated with a different level of trust compared to randomwebsite.com. For example, if you go to your security settings in Internet Explorer, there is an "Internet" zone but also a "Local intranet" zone. If you compare the two, you'll see they have different security settings. By hosting the payload on an external domain, we ensure that we are simulating an identical environment that existed for the attack (and are not subject to a different level of trust).
Editing the HOSTS file has nothing to do with where the resource is hosted. It just allows you to control name resolution without doing it in DNS. Internet Explorer security zones work the same way irrespective of whether a local HOSTS file for DNS resolves the name.
Yes, but at the time I already had an existing domain with a web server I could use. You are correct that I could have setup a separate site for hidusi[.]com and then point the domain directly at my web server's IP, but since I already had a domain/web server configured, it was much easier just to swap the domain in the document.
I can assure you the answer clicked before my research ever started. Unless I am using web server software that responds with one site for multiple host names, you generally need to configure each host name that might be used with your web server as a different "site" (i.e Apache) / configuration. I could have simply edited my hosts file with hidusi[.]com pointing to my web server and created a separate site configuration to serve the hidusi[.]com domain with the second stage. What I was saying in my last response was that instead of using my hosts and having to create this new site configuration (or modify existing with an alias), I could just swap out the domain in the document and use my web server's current state without any additional modification required. It was simply more convenient to change a single domain rather than update my web server's configuration to support requests for the hidusi[.]com alias. There is no significance to using the original domain for serving the second stage, I think you all are all just overthinking it :)
All web servers respond to all hostnames. It is the default unless you have configured it otherwise.
In the event you are doing virtual hosts in Apache, you just add a single line:
ServerAlias www.example.com
And your webserver will respond when queried via this hostname.
So, even in the worst case scenario, we are talking about two very basic lines of text to accomplish your goal.
The whole setup should take about 60 seconds.
I am not trying to say that your approach is wrong, but just that there is a much simpler way to go about accomplishing this goal.
As far as "overthinking it".. I think we are going to have to disagree here because I am unable to see how your method of reverse engineering can possibly be simpler than something that takes practically no time or effort.
At any rate, this is not an argument, I just want you to be aware of your options as you continue your research.
I wish you luck as you continue exploring, and thanks for the writeup :)
Dell SupportAssist comes pre-installed on most new Dell machines. The only reason it wasn't installed on my machine is because the drive I used was not prepared by Dell. Your average Dell user will have SupportAssist installed though you are right that it can be uninstalled.
There were a bunch of ways to bypass the check. For example another way would be to use "http:\\" which wouldn't get detected either. The new version isn't vulnerable.
More details on these scenarios:
1. A remote attacker with no privileges in a man-in-the-middle (MitM) position could leverage the issue against a victim machine that uses HTTP boot. No direct access to the victim machine is required.
2. A remote attacker with privileges and code execution on the victim machine could leverage the issue to bypass Secure Boot, even if the victim does not already use HTTP boot (as long as firmware has HTTP support). How? Several ways:
3. An adjacent attacker with no privileges in a man-in-the-middle (MitM) position could leverage the issue against a victim machine that uses PXE boot. PXE is separate from HTTP boot, but similar to the local vector, an attacker can chain together shim (via PXE)->GRUB2 (via PXE)->shim (via HTTP).