I saw this item in my CodeProject Newsletter. If you administer a server, server farm, any server implementation that uses PXE, or even if PXE is enabled on your computer, and you run an OS from a server on it, I strongly suggest you read this:
[New UEFI vulnerabilities send firmware devs industry wide scrambling | Ars Technica]
I hope this is informative and helpful,
Ernie
o crap⌠lol
I know this sounds bad, but there is an easy fix for average computer users. Go into the UEFI interface, and disable PXE. For server operators, the solution isnât so simple, but firmware patches are coming to close/eliminate these vulnerabilities. Check with your hardware sellers/manufacturers.
Ernie
Wondering if Iâm in any worse shape because I have a PXE server in my homelab⌠lol
Sorry, but I can not see why anyone would want to boot a home computer from the network.
Unnecessary complication breeds trouble.
I mostly use it to boot VMs on my servers so I donât need a bunch of ISOs.
I donât know, but if I were you, Iâd check to see if there are any firmware updates for the machine youâre running the server on. Does your server face the Internet, or is it only on your LAN? If the computer your server runs on isnât in your routerâs/gatewayâs DMZ, and your router is configured to ignore all incoming connection requests, that should mitigate this danger until a firmware update becomes available, at least to some degree.
I hope this helps,
Ernie
nah, nothing faces the internet in my homelab. I try to avoid doing that if I canâŚ
OK so you use PXE over a virtual network
Why dont you boot the VMâs from a qcow2 file?.. Oh I get it, you probably do, but the qcow2 files are on the server?
Exactly.
The basic idea of security is to hide everything.
yep, exactly.
And mostly I just like to experiment with stuff. I enjoy things âtalking to each otherâ ⌠lol
Pardon me if Iâm too far away on the non-paranoid side!
Quote from the article:
An attacker doesnât need to have physical access neither to the client nor the boot server. The attacker just needs to have access to the network where all these systems are running and it needs to have the ability to capture packets and to inject packets or transmit packets.
So this is a problem for hosters, where they offer virtual machines for rent basically to anyone. So the hoster does not have a control over what programs the VMâs run.
Theoretically a malicious renter could run a packet-sniffer on the rented VM, and inject malicious packets into the local netwrok from that VM, so achieving infected boots of other VMâs.
So the problem starts when an already malicious machine (VM) runs in the local network.
So if you donât install malacious things (e.g. from a questionable source), tha attacker cannot get into your local network to sniff, and inject in the very right time (just shortly before your own DHCP server answersâŚ)
So I donât think this is a huge threat to homelabs, like @Doron_Beit-Halahmi has, unless there are VMâs under control of unknown people.
Even if the server is in DMZ, I donât think PXE boot is infectable from outside.
DMZ just means, that all requests are transmitted to that DMZ-ed IP, but when that target server boots, doesnât have an IP yetâŚ
Even if DMZ is enabled, sniffing internal network traffic is not possible from outside, is it?
If the miscreants canât âseeâ my home network on the Internet, they wonât know itâs there to be attacked. Thatâs why I configure my router to ignore all incoming connection requests rather than to refuse them. When the router ignores incoming connection requests on all ports, it doesnât respond at all. When it denies them, it sends a response informing the caller that their request has been denied. I want my router to be as invisible on the Internet as possible.
The website I use to check my home networkâs security is Shields Up! You can check your routerâs Internet port configurations, learn what a port is, and which ports are used for what. Thereâs a lot of other related information there too.
Ernie
Exactly. The basis of all security is to be invisible.