The EFI system partition is a partition on the disk, it is not a firmware component. It’s usually the first partition on a disk, usually uses the FAT32 filesystem, and usually has a directory named EFI in it.
I have no further comment on top what is documented in the wiki page that I liked to.
This is out of scope for support on this forum.
User documentation, actionable steps what users can do are documented in the wiki as far as we could document it. There is also a lot information about past attacks, potential attacks and tons of links you can follow to learn more.
Discussion on specific attacks on EFI are out of scope. There’s a a plethora of information on the internet. Search terms such as:
attacks on EFI
breaking firmware
There are many websites and video presentations dealing with this topic.
There is so much information, if you wish to study this, they can keep you busy for years.
Yes, it is theoretically possible to PXE boot a bootkit/rootkit or an RTOS remotely, but it requires control over the network infrastructure or exploitation of vulnerabilities in the PXE boot process.
Conditions for PXE Attack:
The attacker must have control over the network infrastructure (e.g., DHCP or TFTP servers).
The target system must be configured to PXE boot from the network (e.g., in a corporate or lab environment).
Security measures like Secure Boot or UEFI firmware passwords may need to be bypassed or disabled.
If your main concern with PXE is something along the lines of data centers in the scenario of installing Kicksecure on VPS, well then that something outside your control or the operating system you install.
If your talking about PXE on personal computer like a laptop or desktop. Well, then here are some mitigation suggestions you can do within your control.
Disable PXE boot in BIOS:
In the BIOS look for PXE boot related settings and Disable them.
- Boot Sequence: uncheck integrated NIC as a boot option
- System Configuration/Integrated NIC: Make sure to only select the “Enabled option” Not the Enabled wPXE option
- Disable anything related to “Network boot” or “Boot from LAN” might be in POST section options.
Block PXE-Related Port (Port 69) on Network Firewall:
Block port 69 Trivial File Transfer Protocol (TFTP) via on your WiFi networks Firewall. This means blocking incoming/outgoing of port 69 on UDP/TCP it mainly uses UDP but to be safe or for simplicity do both.
Blocking port 69 alone does not affect DHCP, but it does prevent the subsequent TFTP transfer. There may be alternative ports or protocols that could be used for PXE booting, potentially bypassing the block on port 69. Traditionally PXE booting via TFTP is done via port 69 UDP. Blocking it on the operating systems firewall is useless, this needs to be done at the network level (Network Firewall). This is because PXE boot is intialized before the OS is even loaded.
Do not block port 67 and 68 cause these are utilized for DHCP and it will cause you experience issues obtaining an IP address from a DHCP server which translates to not being able to connect to the internet.
Use Open-Source Firmware (Coreboot/Libreboot):
Opt for a computer that you can install a Coreboot or Libreboot on. PXE boot functionality is not included by default in either Coreboot or Libreboot. It has to specifically be selected when compiled with compatible configuration payloads.
Combining all three suggestions (Ideally number 3 is best mitigation) would be the best measures. However not everyone may be able to do this so combining method 2 and 3 would be good mitigation option given if you cant flash an open source firmware as such that strips PXE capability out of the firmware.
Do you mean install it on Raspberry Pi and use the Pi as form of external media as if it was a flash drive to boot into Kicksecure from?
I’m sensing this this related to DMA (Direct Memory Access) concerns?
Most standard 2.0 USB devices, such as flash drives, typically do not use DMA. However, high speed USB devices, such as flash drives like USB 3.0 and later controllers often do include DMA features for high-speed data transfer.
The USB host controller, part of the system chipset, may use DMA to manage data transfers. This means even if the USB device itself doesn’t use DMA, the controller might, introducing a potential attack vector. In the case that the USB port is USB 3.0 rated but the USB device is USB 2.0 rated.
IOMMU (Input-Output Memory Management Unit) to isolate device memory access, mitigating DMA attack risks is already enabled in Kicksecure by default.
Raspberry Pi’s do have DMA (Direct Memory Access) BTW just to let you know but you might be able to disable some functionality in the config file but I have never looked into it before.