The nine vulnerabilities that comprise PixieFail reside in TianoCore EDK II, an open source implementation of the UEFI specification. The implementation is incorporated into offerings from Arm Ltd., Insyde, AMI, Phoenix Technologies, and Microsoft. The flaws reside in functions related to IPv6, the successor to the IPv4 Internet Protocol network address system. They can be exploited in what’s known as the PXE, or Preboot Execution Environment, when it’s configured to use IPv6.
Not all hardware manufacturers are effected and it's based on a specific open source implementation of UEFI.
You may be right, I didn't think those three were that much of the market, but maybe I'm wrong.
I thought Tiano was a reference UEFI developed by Intel? So I'm not entirely sure its used by AMD, but maybe it is?
EDK and EDK II are open source projects that spun off of that reference developed by Intel.
I suppose the main thing I was trying to get across is that OP seemed to be blaming motherboard manufacturers for bad code... but this is the base open source code that is causing the issues, prior to implementation by motherboard manufacturers. Hence why it impacts so many.
As for most board vendors nowadays, I think they barely do anything with the code itself and just create the setup utility and boot logos. It is highly likely that they're affected too.
Short for Unified Extensible Firmware Interface, UEFI is the low-level and complex chain of firmware responsible for booting up virtually every modern computer.
The flaws reside in functions related to IPv6, the successor to the IPv4 Internet Protocol network address system. They can be exploited in what’s known as the PXE, or Preboot Execution Environment, when it’s configured to use IPv6.
... UEFI (Unified Extensible Firmware Interface) replaces the BIOS (Basic Input Output Software) which was present in the boot ROM (Read Only Memory) of all personal computers ...
PXE, or network boot. It is basically never used (and rarely enabled, if ever, by default) by the individual, but can be helpful in, for example, a large scale OS deployment. Say IT has to get their corporate image version of Windows 10/11 installed on 30 new laptops. They could write a ton of flash drives, but it'd be easier to just host a PXE boot server and every laptop just listen to them.
V6 specifically in that instance would just be for the reason of "we need to move away from v4 anyways"
Slaac does everything for you. You get dynamic public addresses that change (you can disable if you please). Nothing to deal with, just open a firewall port if you want to receive traffic
I want static addresses on my LAN, and addresses I can remember and easily recognize in a list. And I don't want my devices to have unique addresses outside my LAN, especially not static ones. NAT is great.
See, what both of you wrote is completely alien and confusing to me. The look of IPv6 gives me an aneurysm. Let me keep my IPv4. You can run IPv6 on your own LAN. I'm not stopping you.
It's a little bit unfamiliar, not the end of the world. It's not complicated and not as nuanced as ipv4 networking. No dhcp necessary anymore on your local network, how good is that? No more trying to hardcode MTU, no strict/open/hairpin/fullcone/etc NAT issues because no NAT, no port forwarding, no fear of IP collisions, less overhead, freedom of many public addresses per interface - host each app on its own public IP address if you desire. Ipv4 over ipv6 is part of the spec so you would never lose ipv4 connectivity. I could go on
Oh I'm sure you can do heaps more with IPv6. And that's great. I'm just saying to me it's super complicated because I have to learn everything from scratch, and again those horrendous long and complicated hex addresses. If I can live my whole life without ever having to type or trying to remember an IPv6 address I'll be a happy guy. IPv4 is super clean and easy at least on the level I'm using it. Those negative things you mention, I've never had to deal with any of that. Except port forwarding, but that's easy and honestly I kinda like how that works for some reason.
But sure, you mention some pretty cool things there with IPv6 that could perhaps come in handy even for me at some point when I start doing more advanced things on my network. So I'll keep that in mind for when that happens. And also, I guess I probably should learn more about IPv6 just to have the knowledge for when I might need it, wherever that may be. But ugh... lol
My brain stops me from remembering and recognizing IPv6 addresses. I can't deal with long strings of hex. And why are people so against me running IPv4 on my own LAN? Do I make you sad? Do I ruin your day? I love IPv4, and NAT works perfectly fine for me. I'm not doing the translation, my router is.
You don't need to have long addresses, you should be using hostnames and domains anyway. Ipv6 addresses are often simpler than ipv4 ones. E.g. prefix::1 for your router. Prefix::2 for the next device, and so on to Prefix::FFFF for the first 65k machines if you wish to set it up that way. Ipv4 exclusively on your lan ruins my day because I have to maintain servers and software to support users that only use ipv4 and flat out refuse ipv6 connectivity - it's expensive and takes a lot of effort to maintain dual stack support.
Most of the time I do use hostnames, but it doesn't matter what I use as a user if I have a list of addresses I have to look through in log files, or enter addresses for configuration or whatever. My brain works on IPv4. I'm sorry for ruining your day, but I assume, or at least hope, that you get paid for the work. I do not and I have more important and pressing things to do than learn IPv6 and reconfigure my whole network.
Ideally, using just IP6 would be simpler, as every device gets a global address. Then you don't need to mess with NAT, port forwarding and all that bullshit. Every device having multiple addresses just complicates things.
A device on your private IPv4 network can send packets directly to 104.21.36.127 via NAT. How will it send packets to 2606:4700:3033::6815:247f? There's not enough space in the IPv4 header.
A lot of the world, especially Africa and south America, was somewhat later in adopting the Internet and has a much smaller supply of IPv4 addresses. People with ISPs there need IPv6 to be directly connectable without CGNAT
The vulnerabilities, which collectively have been dubbed PixieFail by the researchers who discovered them, pose a threat mostly to public and private data centers and possibly other enterprise settings.
People with even minimal access to such a network—say a paying customer, a low-level employee, or an attacker who has already gained limited entry—can exploit the vulnerabilities to infect connected devices with a malicious UEFI.
By installing malicious firmware that runs prior to the loading of a main OS, UEFI infections can’t be detected or removed using standard endpoint protections.
The malicious image in this scenario will establish a permanent beachhead on the device that’s installed prior to the loading of the OS and any security software that would normally flag infections.
This kind of access may be possible when someone has a legitimate account with a cloud service or after first exploiting a separate vulnerability that gives limited system rights.
When the client-{based server] boots, the attacker just needs to send the client a malicious packet in the [request] response that will trigger some of these vulns.
The original article contains 703 words, the summary contains 177 words. Saved 75%. I'm a bot and I'm open source!