andigandhi
EFI Stub: UEFI Secure Boot is enabled
Hi,
First off, many thanks for taking the time to develop & release a PoC for this exploit!
I'm currently a bit stuck, I'm able to PXE boot to grub on two test laptops, but as soon as I attempt to boot into Linux I get the error:
EFI Stub: UEFI Secure Boot is enabled
Thank you very much, I already saw that you also did some research regarding th bitpixie topic :D
The EFI Stub: UEFI Secure Boot is enabled message is no real error message, it is also shown for a small timeframe on a successful boot. It seems as the boot process gets stuck afterwards when loading the kernel.
How long did you wait? The kernel might take some time to be transferred via TFTP. Today I also released the v0.1 version of the exploit, it contains an up-to-date alpine-initrd.xz image, you might want to try it as in this release all of the cross-dependencies are correct :)
Also can you post your ip a output on the attacker machine? Sometimes the IP addresses are a bit messed up (e.g. twice the 10.13.37.100/24 network).
I didn't wait that long, showing my impatience it seems haha. Thank you for the clarification on the message.
I did have a dabble myself, but this is way outside my skill set.
IP a output only shows one 10.13.37.100/24 network I do get messages from dnsmasq stating that the ethernet device has no IP address now and again. I usually fix by assigning 10.13.37.100/24 or 10.13.37.101/24 manually.
I think there's an issue with my setup. I'll have a play around and update if I find what's wrong.
Give it time... and look at the tftp logs... black screens of up to a minute are possible... at least on my test machine.
I've waited up to 20 minutes - last entry from tftp logs is the sending of alpine-initrd.xz
Give it time... and look at the tftp logs... black screens of up to a minute are possible... at least on my test machine.
Very strange... If something similar happens to me or my colleagues, I will get in touch. Otherwise, a remote diagnosis is somewhat complicated in this case
It can be really slow. My attack computer is an emulated x86 machine on ARM (Mac M1) only connected via wifi to the network. I wait about 10 minutes to boot the target computer. 😅
You can massively speed up the transmission if you adjust the TFTP Block Size. On a physical HP I have found it to be default at 4, but increasing it to like 512 massively improved loading speeds. I though do not recommend going bigger than 1500b because of the MTU size. Any value higher than 1500 respectively something like 1430b as the packet itself has some header stuff, will make it slower again, as the block will be fragmented...
I've monitored the entire process with Wireshark and the initrd gets transferred across fine. So I don't think transfer speed is the issue, something must be breaking when it's trying to load the kernel.
Well it seems that this issue might fall under the other supported devices issue. Both my initial test laptops were HP. Unable to get past the EFI stub, however I now have a Dell which is able to boot into Linux. The VMK cannot be found, but at least rules out an issue with my tftp server setup.
Strange, thank you for sharing your experience! For the Dell: Is secureboot activated and are only the protectors 7 and 11 active? I never had any problems scanning for the VMK if these prerequisites were met on Dell machines...
Strange, thank you for sharing your experience! For the Dell: Is secureboot activated and are only the protectors 7 and 11 active? I never had any problems scanning for the VMK if these prerequisites were met on Dell machines...
Secure boot is enabled, but I didn't check the protectors. Just did and PCR 4 is present...
I've got access to a fair amount of devices, so I'll get a list of working/non-working devices going.
Is PCR 4 also present on the HP machines? If PCR4 is present the exploit will not work.
Is PCR 4 also present on the HP machines? If PCR4 is present the exploit will not work.
No
There are many pitfalls when it comes to this attack... I had issues with Ethernet Adapters: Surface for example allows only their own adapters to PXE boot (officially mentioned here: https://learn.microsoft.com/en-us/surface/ethernet-adapters-and-surface-device-deployment)
Further: PCR 4, 7 & 11 have been rolled out as default around July 2024 (right after crowd strike) to mitigate bitpixie, but the update has been revoked as certain platforms extend PCR4 with additional random stuff which renders the devices useless (BitLocker Recovery Password prompt every now and then).
Default today should be 7&11 if secureboot is enabled and 0,2,4, 11 if no secureboot is present. The latter is not vulnerable to bitpixie.
Regarding your HPs: Did they even PXE Boot at all? HP has some fancy security measures in their UEFI which prevent many low level attacks during the boot process... maybe they invented something new 🤷♂️
There are many pitfalls when it comes to this attack... I had issues with Ethernet Adapters: Surface for example allows only their own adapters to PXE boot (officially mentioned here: https://learn.microsoft.com/en-us/surface/ethernet-adapters-and-surface-device-deployment)
Further: PCR 4, 7 & 11 have been rolled out as default around July 2024 (right after crowd strike) to mitigate bitpixie, but the update has been revoked as certain platforms extend PCR4 with additional random stuff which renders the devices useless (BitLocker Recovery Password prompt every now and then).
Default today should be 7&11 if secureboot is enabled and 0,2,4, 11 if no secureboot is present. The latter is not vulnerable to bitpixie.
Regarding your HPs: Did they even PXE Boot at all? HP has some fancy security measures in their UEFI which prevent many low level attacks during the boot process... maybe they invented something new 🤷♂️
It's very strange, both HP laptops were able to PXE boot and I can see that the initrd was transferred across. But they both hang at EFI STUB, I've even left the device overnight and it progresses no further. I've tried both this repo and Martannes to the same effect.