Code-execution flaw in UEFI firmware threatens most servers on planet Earth
j / k
|
Down or up a comment |
h / l
|
Previous or next link |
?
|
This help |
[1] https://tinfoil.sh/blog/2026-10-25-less-is-more
Trying to keep code small could backfire by ballooning dependency on dependencies to do more of the work.
The unix philosophy prevails!
EDITED TO ADD: If you’re looking for a UNIX anti-hero regarding “do one thing and do it well” (that predates systemd), look no further than emacs.
Funding FOSS projects without advertising, dopamine-hacking, donation-begging into the void, or being subsidized by billionaires that want to influence the electorate is still largely unsolved.
The problem isn't even the billionaires.
The problem is convincing comfortable, ambitious middle-high earners to put a cap on their and their bosses' prospects in exchange for the stability (and subsequent ground preparation for innovation) of a higher floor.
They're the stumbling block because they're the ones who, on balance and en masse, have the money and votng power to excuse and enable the status quo.
Part of the problem is that there are people who think all rather than only some of those things are a good idea.
High marginal tax rates and taxing unrealized gains are both unintended consequences factories. Especially the second one, but even the first one is basically a trade off between creating perverse incentives and arbitrage opportunities (i.e. massive loopholes) because the high rates don't apply to everything, or supercharging offshoring because the high rates do apply to everything.
Conversely, a UBI is a good idea, and doesn't actually require oppressive tax rates because it replaces most of the existing system of government benefits and subsidies -- which impose even higher de facto marginal tax rates on most of the middle class in the form of benefits phase outs. US federal spending is already >$20,000 per capita.
Not all of that is assistance programs, but a large proportion of it is. And most of those programs are a net negative compared to reallocating their budgets to a UBI. Having separate bureaucracies to administer separate programs for food assistance, housing assistance, education assistance, etc. is foolish even before they create weird marginal rate cliffs and higher marginal rates on lower income people by having arbitrarily overlapping phase out rates.
It isn't about the source of the money. Converting those things to a UBI would cost less money to give people more money because you'd save the amount spent on administration, while improving economic efficiency by not imposing arbitrary restrictions on how it's spent. The primary reason we don't do that isn't upper middle class people demanding a status quo in their own interest -- it isn't in their interest.
It's a combination of ordinary incompetence and bad structural incentives because politicians like to claim credit for creating new programs instead of just indexing the amount of a cash payment everybody gets to GDP per capita and then sending them all home.
You might want to remind yourself what caused the November 2025 Cloudflare outage!
Dependencies are.
Part of that is reading bits and pieces of what Nancy Leveson had to say about the subject. Subsystems even when working to spec can produce spectacular failures.
中国特色. And an even larger gap vis optimized-for-pharma US IP config (Industrial Policy).
I'm happy if LLMs and the semiconductor shortage will create a renaissance of native applications.
But would you give up packages, central repositories, downloads that Just Work without patching, public version control systems, open-source software, ... , and much of what they enabled?
"Civilization advances by extending the number of important operations which we can perform without thinking about them." - Alfred North Whitehead, An Introduction to Mathematics (1911)
Getting packed into 2026 airline seats can be a "miserable experience". But that taken-for-granted human flight... a cramped seat in the effin clouds... is what? A century or two of focused effort, eventually massive effort, building that dream? Another century pursuing the dream of compact mechanical power? 10 millennia on metallurgy? So one's flight may have sucked, and there are many downsides to aviation existing... but living the dream of human flight, isn't living in a dream of no problems and effortless happily ever afters.
But yes, I'm so looking forward to agentic full-stack-ish rewrites, slashing through decades of accumulated stagnant cruft. Laptop-like angular-resolution HMDs are this-year-ish (though expensive, not mass market). And doing such rewrites by hand is a pain. Someone reports a Claude one-shot which installed a PICO Space Pro dev env, created a simple app, uploaded the apk to the headset, and responded with "ready for you to test"... and it was. Wild ride incoming. Though that's perhaps not a minimalist/efficient renaissance you had in mind? Still, in the midst of upset, there's opportunity to pursue visions which might not be viable in more settled times.
Systemic problems everywhere, Woody!
Sysvinit, it's a 1000 lines of code, maybe a bit more. It's a rock compared to systemd.
So many devs have zero issue with large codebases. Some substitute "small" with "perceived small because I pull in 10M lines of node and composer packages".
And of course the new goal is to bring "trusted computing", eg Microsoft style EEE to Linux with Lennart's now corporate gig.
But it is a different world. So, what can you do?
So you're correct that sysvinit is more than an order of magnitude smaller and simpler than systemd, and having all that code in your TCB is an express ticket to the bug-of-the-month club. But you're still underestimating sysvinit by an order of magnitude.
Bringing Treacherous Computing to Linux is, of course, generally a bad thing, and it's not a good idea to have the lead maintainer of the central component of your operating system employed by a notoriously unethical company whose main product is a competing operating system.
Frankly the amount of crying I have seen about systemd... and it's basically the most stable part of my Linux installs. Even though I really have seen everything else "catch on fire".
Systemd doesn't just replace 1000 lines of Sysvinit. Those "millions of lines" also replace the thousands of hundred-line poorly-vetted Bash scripts you need, plus your syslog daemon, plus dozens of "fork, setuid, chroot" variants, plus your cron daemon. And that's before we get into things not directly related to service management, like logind, hostnamed, networkd, resolved, timesyncd, tmpfiles, udevd, and so on.
Systemd is an umbrella project. Look at each individual component in isolation, and the vast majority of the time the thing it replaces is significantly more complex and fragile. Systemd was adopted by most of the Linux ecosystem because it was a significant improvement over the status quo, there is no need to invent conspiracy theories here.
When people say systemd they really mean systemd-init, which is one piece of software. Not systemd-resolved, which is another.
Most distributions only use some of them, and the “some” set is different from distro to distro. Many distros swap parts out. And some distros only use systemd-resolved.
Systemd is, legitimately, well divided. Most of the complaints against systemd are from people who know basically nothing about systemd.
How many pieces of software is nginx or Apache, where every feature is an optional plugin?
E.g. explorer.exe is not replaceable on windows so the display server and that is one software. (The kernel is NOT though, because it can surely run in a headless way). It's not that hard of a concept..
A new service manager for Linux distributions. The last piece of a full alternative to systemd. https://skarnet.com/projects/service-manager.html. This is a proof of concept, it does not yet have its final form.
Usually your inittab only includes gettys, shutdown/reboot, and launching rc. That's the only things sysvinit does and it's not even the best way to do them.
Complete opposite of my experience. I've never had a single problem with SystemD - it's one of the most surprisingly reliable parts of Linux IMO.
In contrast SysVInit worked ok on servers and sort of on desktops, but on laptops forget it.
Since 2005, for more than 2 decades, I have used on all my laptops only Linux with Gentoo and SysVInit and I have never encountered any problem.
Perhaps you mean that your particular Linux distribution had some startup shell scripts (which are not a part of SysVinit, they are only launched by SysVInit when the run level is changed) that were buggy on laptops. Buggy initialization shell scripts are not unusual, but such scripts are normally small and any bugs are relatively easy to find and fix, unlike with the bugs of SystemD.
While you did not had any single problem with SystemD, when I first tried SystemD (with Arch Linux; that was many years ago and that specific bug must have been fixed some time later, but nonetheless it convinced me that the developers of SystemD are incompetent), SystemD exhibited the most stupid bug that I have ever seen in a computer, i.e. the shutdown of the computer was very slow in comparison with SysVInit and moreover it sometimes failed, which is a thing that I have never seen in a computer elsewhere.
The reason for failure was that SystemD, instead of just sending signals to all processes like SysVInit, it used some inter-process messaging through DBus. At that time, at least on my computer, there was some kind of race condition between the concurrent processes that were terminated and some times DBus died before some other process that tried to communicate through it and then the SystemD shutdown sequence remained stuck and it never completed.
I consider such a bug much worse than a bug caused by carelessness, like a buffer overflow, because it demonstrated an erroneous design of the architecture of the system.
You can't really separate the buggy SysVinit shell scripts from SysVinit itself. That's classic "guns don't kill people, people kill people".
I prefer to not get shot.
"Now"? It's always been that way. Most developers just didn't want to admit it because it meant more work and that their past existing work was shite.
Sounds like it wasn't very usable
And that is why it is now more usable. More affordable.
That article makes good re-reading in the "Penetrate and Patch" section now, in the days of AI exploits popping up faster and faster.
[1] https://www.ranum.com/security/computer_security/editorials/...
We need a clean start. A lot of layers can and should be rebuilt, and even if you do it without reducing functionality, I feel like in a lot of cases like we’ll be able to cut down the code significantly.
When I explain software bloat to non technical people, I say imagine you built a 10 story building, but every few years it was a story at a time with the renovations along the way.
Like there’s gonna be a lot of inefficiencies. Yea I know we refactor. But doing a clean slate rebuild. Knowing exactly what you need based on real world experience, it should work to really streamline stuff.
See the Versailles Wedding Hall collapse in Israel, 2001: https://en.wikipedia.org/wiki/Versailles_wedding_hall_disast...
""" An initial inquiry blamed the collapse on the Pal-Kal method of constructing light-weight coffered concrete floor systems which was banned shortly after …
Late in the construction process … a third storey was added. … the structure supporting the new third storey was subjected to much greater loading than was originally anticipated. … somewhat mitigated by the construction of partitions on the floor below …
A few weeks before the collapse, the wedding hall owners decided to remove the partitions. … the floor above began to sag several centimetres. The owners viewed the sagging floor primarily as a cosmetic problem, and attempted to level it with additional grout and fill … a new and significant dead load at the weakened area. """
But think about it: they can and will “start from scratch” whenever they see the need to do so, while software engineers have been forced to cope with bad decisions from the 80s because the cost of starting fresh was simply unaffordable for most projects.
So the solutions need to be structural.
e.g. relative to a monolith kernel, seL4 is small, has no known bugs (AI can try, but so far crickets) and is the only piece that needs to run privileged.
Everything running under seL4 benefits from the guarantees seL4 provides.
seL4 is the choice that allows for a safe system to be built. Any other choice of kernel currently available does lack the mechanisms and guarantees.
The blog-post is written by AI. I am more than interested to hear a human talk about it but AI generated blog post removes that interest.
The article that I am talking about which is generated by AI is this one: https://tinfoil.sh/blog/2026-10-25-less-is-more
Hope this clears up the confusion!
I then tested it on pangram and gptzero and pangram does say 97% human and only 3% AI and GPTzero says 100% human
For some reason, my AI spidey sense had activated and I used the new AI text detector and it had a false positive maybe.
But I was wrong and since this is written by human, now I will read it :-D
An interesting observation that I have made here is the amount of stickiness that Pangram and others can have. I tried a new AI text detector and it failed and because of it I falsely accused someone of AI writing. Now I would prefer not to use that. So AI text detectors have this sort of effect where they have to be really effective and false positives/negatives can change a lot of things/interactions.
My apologies though once again that I said that it was AI generated when it wasn't!
[0]: https://news.ycombinator.com/item?id=50220254
I guess this is what they are doing.
So, just normal BIOS boot?
And unlike BIOS which is relatively small UEFI is "full-fat" almost the size of an operating system itself. It can even run its own applications.
The 1 million lines of C code comprising UEFI are riddled with bugs and this is just one of them. No doubt LLMs will be able to uncover a lot more of them.
Yes it does? If anything, it provides way more; a .efi program can use firmware services to load files and print text. There's like 80% of a DOS in there.
> Most operating system don't use BIOS or any other software layer and configure the hardware themselves. Why is it there then?
Because we still want enough functionality to load the OS in the first place, which means e.g. nvme drivers, Ethernet drivers (for netboot), keyboard input and some display output (to let a user pick what to load), and of course filesystem drivers because loading an OS/bootloader from a single shared MBR was awful.
I'm not really sure what this means. UEFI provides a consistent interface to access storage devices, network devices, input devices, and access to a framebuffer. How else would bootloaders work?
And why do I need mouse and network? Just so the BIOS firmware can show me a graphical interface and connect directly to the internet?
Also uboot is firmware, there's no lower layer it runs on so of course it has to include the device tree. Or in practice, like most vendors, you just put the device tree in the kernel because you know your kernel runs on one specific device model anyway and then you can just edit it when you discover why it's wrong, instead of doing a weird dynamic patching thing.
When vendors ship a specific kernel, you are unlikely to get security updates in a timely fashion, if ever.
There should be no need for any of this in 2026.
The installed kernel has 200+ dtbs shipped with it and the boot loader has to be configured by some non-standard userspace glue to detect the correct dtb before rebooting. This glue doesn't exist everywhere and can be ad-hoc per-board or completely non-existent. IMHO, this leads to folks just not updating kernels.
One nice thing (in theory) about a dtb is that there is no code. Of course, there doesn't seem to be an established standard for finding that data so we are back to relying on specialized boot configuration and code anyway.
One place this all becomes glaringly bad is if you take an SD card and move it from one arm64 node to another; There is a good chance it won't boot. It's no wonder there are so many board-specific OS-images floating around instead of having arm64 installers that just work.
Also, a FDT is useless to most OS and remains primarily a Linux concept that has bled into other spheres (like U-Boot) so why would a manufacturer include it?
So ... what should we actually have? A standard on arm that doesn't depend on the triple of which (OS,board,bootloader) you are running. We should be able to just build an arm64 kernel (BSD/Linux/Windows/whatever...) and have a good chance that the thing just works. If that's done via UEFI, then so be it.
IMHO, given (waves hands) the current state of arm64 boards, arm64 support for Linux should look like:
1) Load a board-specific firmware to provide UEFI via EDK2/U-Boot/custom * This is likely on the board-manufacturer to provide and should be pre-loaded.
2) Run a generic arm64 installer.
You wouldn't want the boot ROM to implement UEFI. It would have many unpatchable bugs and different ones on every device revision. Better to put the UEFI where you can patch it. For instance on a Pinephone booting from SD card, the firmware is on the SD card. Moving the SD card to a different device is putting the wrong firmware on that device, that's why it doesn't boot.
And then once you're shipping your own UEFI impl and shipping a kernel that runs inside UEFI, you'd quite rightly wonder why you don't just short circuit those two layers and run the kernel directly on the hardware.
There are also less-powerful RK3588-based boards like the Radxa Rock5 series which are supported by this edk2 port: https://github.com/edk2-porting/edk2-rk3588#platinum. Thanks to collabora the mainline support is quite advanced: https://gitlab.collabora.com/hardware-enablement/rockchip-35...
If you are searching for more powerful enterprise hardware, AmpereOne SoCs have ARM SR certification. You can just use any modern linux distro uefi generic aarch64 iso and it will boot.
Before the only way was either fdisk /mbr to reset for Windows or boot a Linux system on stick/CD and rebuild grub/lilo. The latter has gotten unreasonably complex though so I rather wouldn't do this manually.
My verdict is that UEFI does something right, but created for the enterprise sector carries way too much complexity. Obviously so complex that everybody ends up using the original same code base.
The absolute hackery that was necessary for BIOS to do something as basic as booting an operating system was due for removal. And looking at the rest of the bootstrapping landscape (ARM phones, Linux routers, you name it), I'll take UEFI over any of its competitors any day of the week.
If most vendors suck at writing firmware, it might be a problem with the spec though.
Most of the alternatives require brand+model specific kernels and boot mechanisms, at least UEFI has a standard. I dream of the day smartphones run UEFI instead of the weird factory bootloader + custom uBoot mess that we're in right now.
To boot an OS you need to initialize core 0, RAM and some storage controller. Throw in a serial port for debugging. Everything else should probably be left to whatever is running at the initialization vector of the storage. Which, if you'd like, can be a complete UEFI implementation.
Having a display, mouse, keyboard or network is an opinion. GUID partitions are an opinion. And if it comes to opinions, I'd rather all of the extras be handled by third parties instead of within a giant spec that will be vibe-conformed to.
There are plenty of things I don't like about UEFI. Going for pseudo-Windows APIs, for instance, or using FAT as a filesystem while better open-source filesystems are available.
I do applaud the efforts of people like the Coreboot team, trying to take control back for their devices, but the cut-down minimal boot manager they provide has yet to convince me to even try switching, to be honest.
USB is a value-added feature (with a spec that rivals UEFI in complexity), and despite having owned 5 apple machines, I'm not sure I have ever used thunderbolt... EVER
With regards to trust, the only reasonable approach is "can be overridden by the legitimate owner" with a "delete everything on request by whomever has physical access to the device" fallback. Yeah, theft will be a problem but 1984 would be a bigger problem.
Putting it all in a single location on the storage device means that 1. Multibooting will always suck because Windows will unconditionally overwrite whatever is there with its own bootloader that only boots Windows, and 2. you now have to have local storage, which would be somewhat annoying to those of us trying to do diskless network boot (or anything else more interesting than "always boot internal disk0").
Also why initialize RAM? Isn't cache-as-RAM enough for a stage zero bootloader?
Having to build u-boot for every device model is a good thing, it means that there's less functionality abstracted-away by some never-to-be-updated vendor-provided firmware.
It's also the normal way the entire history of computers has always worked, except for the IBM PC and its derivatives. If you want to install an OS on a 2025 OnePlus Blahdy Blahdy Blah you need to find an OS explicitly built for a 2025 OnePlus Blahdy Blahdy Blah - one for a 2025 OnePlus Blahdy Blahdy or for a 2026 Blahdy Blahdy Blah will not work and will likely just brick your phone. And nobody is out there building every OS for every phone model. But I can install Linux built for a Lenovo laptop onto a Dell desktop or a SuperMicro server.
As to your other point, software is always easier to change than hardware, even if easy means hooking up a ch341a chip. Hardware however always transitions from sand to electron prison to rock to sand.
This is just a copout. Of course the crappy implementations many people have to deal with cast the whole thing in a bad light. If nothing else, UX is a distant-to-nonexistent concern of the UEFI standards, and that's part of the problem.
However, you are also right that this doesn't hardly make UEFI any worse than BIOS.
Needing to do special Windows boot and somehow wiping the boot config has nothing to do with the standard.
UX is meaningless for a boot mechanism standard. You cannot apply the same requirements to all UEFI devices. Tablets need touch-sensitive operations that work without keyboards. Servers need headless management with detailed configuration available through remote management. Desktops and laptops a mix of both. Managed Linux environments such as Chromebooks need a whole different sort of boot mechanism where the user has minimal control.
The update delivery mechanism is specified already. Wiping user settings can also be a necessity. Could be to prevent malicious firmware downgrades, could be to clear out NVRAM-triggered exploits, or maybe because the update necessitated restructuring configuration or whatnot.
Plus, as many have probably already noticed, the UEFI spec is more of a suggestion anyway. The only party bothering to check it might be Microsoft, and even then they only care about the parts that make Windows work. No matter how good or specific your spec is, a shoddy company will release shoddy firmware for it.
Well, all I can really say to this is that yes, this attitude is exactly the problem here.
Of course, the world looks different now than it did 25-30 years ago, and all Intel really set out to do back then was to get away from BIOS and all of its limitations. This was especially important for their now-defunct "IA-64" (Itanium) project, but it ended up lasting anyway due to x86-64 happening.
Nevertheless, for most of us, UEFI rolled out in the 2010s, at a time when Internet connectivity was generally a given, and hardware capabilities had already moved well beyond where they were when Intel handed the matter off to UEFI in the 2000s.
Hardware makers have consistently shown contempt for software and user experience, regarding it somebody else's problem. Of course, a consortium of many hardware makers is not likely to develop opinions or sentiments that none of them individually would have. But it does show how parochial and short-sighted they were and often continue to be.
Yes, there are multiple different platforms that use UEFI. They can each have their own standard way of using it, though.
I don't even want to touch Lenovo devices that don't have "think" in their name, and even that has been tainted by their consumer brand at this point.
A few years ago Lenovo put out a buggy firmware update for the Thunderbolt controllers in a couple generations of Thinkpads (the list is here: https://pcsupport.lenovo.com/ca/en/solutions/ht508988 ) that caused excessive writes to the controller's EEPROM. This would eventually wear out the EEPROM, which would stop the controller from functioning. You would then have issues like USB-C devices not working, display over USB-C not working, and charging over USB-C not working. Lenovo released a firmware update to fix the issue, but everyone whose controller had already broken needed a motherboard replacement. If your device was out of warranty, Lenovo made you pay full price for the new motherboard even though it had broken because of their firmware update.
And yet, I'm still of the opinion that Lenovo's firmware is up there. It's actively maintained and it fails less often than the firmware I've experienced from other brands.
This is less of a compliment to (a branch within) Lenovo, and more of an insult to other brands; production quality for computers and laptops is absolutely awful unless you pay a ridiculous amount of money for the "pro" branding.
You mean, arguably the best vendor of linux laptops since 2005?
Just google around.
Unfortunately we're suffering from "eh, it boots windows, ship it" mentality of many hardware manufacturers, whether back in horrible era of BIOS emulating faux IBM PC 5150, or with modern UEFI
That sucks. I'm able to upgrade the firmware of my checks 8 year old motherboard and its backup firmware from a linux shell.
So you need to 1) Have a server which boots from PXE, 2) Have it do PXE on the same interface used for connections to the internet, 3) Lack a firewall filtering out unexpected or malformed ICMP packages(?), and 4) Do it at the exact moment the physical server is rebooting.
Seems like it is basically zero attack surface when it comes to remotely compromising a server. A client device, on the other hand, would be way easier to exploit, and being able to fool Secure Boot would be very interesting to people trying to bypass DRM or cheat in video games, and of course Evil Maids and security agencies.
Given, without any network level DHCP guard configuration, you could likely also send your own DHCPOFFER and just tell it to PXE-boot your own image :) I suppose for some trusted-boot threat scenarios code execution at the UEFI level is a bigger issue. No idea how modern UEFI PXE-boot deals with signed images.
What we _can_ do, though, while the OS is running is detecting that bogus large ICMP packets are sent continuously. At least, this would be early warning that a reboot may be risky without disabling PXE.
especially in free/open source software like edk2
This is something that shouldn't be possible in the real world because any sysadmin should know not to do this, but guaranteed there are at least some small time operations with a couple of colo'd servers that only have single interfaces serving public traffic, and the intern who set them up didn't know what a boot order was or what "PXE" even did.
Consider a shared or cloud hosting scenario for example.
This may sound like a movie-plot threat in 2020, but perhaps in 2026 it’s less unlikely?
There’s also the theft scenario, as indicated in the article, or the supply chain attack scenario. I don’t know how feasible it would be for a buyer to validate the integrity of the hardware they just racked up if they can’t trust secure boot?
The chaining to get something like this to work is pretty up there.
> The attacker needs only to deliver a unicast ICMP error message addressed to the client's IP, from any network distance.
[1] https://github.com/tianocore/edk2/security/advisories/GHSA-9...
Moreover, Ethernet booting is done usually from separate management networks to which only the administrators are connected, on which also other vulnerable protocols, like IPMI, are used, not from the main network that may have an Internet gateway.
Which is something that happens inside a trust boundary. After all, if an untrusted third party gets to install your OS it's game over, UEFI bug or not.
And consumer devices often don't have a network card - or come with PXE disabled in the BIOS.
It also wasn't uncommon to install a server's hypervisor to a USB flash drive, or a tiny local SSD. Server motherboards with internal USB-A ports (not headers, the entire port) were quite common, and there were even IDE flash drives you could plug straight into the motherboard. This allowed you to completely dedicate the regular storage to the client VMs. I would not be surprised if that same market also used PXE for the same reason in larger installations.
PXE has been enabled by default on most devices I bought, but only after USB and SSD boot failed, so in practice it's not really something you're going to see a lot of.
This gives the attacker access at the UEFI level and above -- they can use it to produce false attestations.
PS your profile links a blog that says you moved
And thanks! Updated my profile.
Seems a bit overblown, couldn't you just serve a malicious boot image anyway?
Sure, there are lots of machines that PXE boot, but if it's on a public facing machine, why would you even configure it to PXE boot?
A bigger question I think is why you'd assign a public IP to a machine for PXE boot rather than booting it from a private IP space then assigning any publics once the OS is booted.
The main question here is how often devices you'd want to try this against have PXE boot enabled. I'm thinking of locked down laptops mostly. Either corporate laptops, or manufacturer locked-down devices (chromebooks, I think some microsoft surfaces).
Even before AI, there was prestige in being able to say that you (or your team) found a 9.2 in some major piece of software. You could put that on your resume in some specializations.
Now with AI vulnerability scanning being so hyper-commercialized (but not yet fully commoditized), this is cranked way up since there are more monied interests involved, and many of them are probably trying to make a quick buck before LLM-based vulnerability scans are a commodity (for better or worse).
Those original PHP 10s were negotiated down into a 9.2 by disclosure.. so maybe this'll be an 8.7 soon.
> Specific configurations should not impact any attribute contributing to the CVSS Base metric assessment , i.e., if a specific configuration is required for an attack to succeed, the vulnerable system should be assessed assuming it is in that configuration. [1]
For a vulnerability to score a 10 its Attack Complexity must be 'Low' (broadly speaking: it doesn't require target-specific customizations or mitigations [1]), which isn't the case with php2shell.
Here's a breakdown of that 9.2: https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:H...
[1] https://www.first.org/cvss/v4.0/specification-document#Attac...
I know my computer has UEFI. But how could a non nation state agent use that vulnerability?
Or is it just about VMs, and it's important, because the whole cloud and internet runs on VMs?
personally never found a reason why to include icmp in there for what i was building using edk2.
as others noted pxe is also already very fragile and enough network access to perform the icmp attack is likely enough access to mitm the entire pxe run and slap in your own boot image or modules etc.
i dont think most servers boot using PXE so that is grossly overstated? or would it include the attacker going into the boot menu and selecting to pxe boot... because why use an exploit then if you can just point it to your own server and again pull the image like that.
all u need is a konboot or similar tool inserted to then subsequently load the original image -_-
I'm wondering if this is the same.
Moreover, in well configured networks there is typically a separate network for the management Ethernet interfaces of the servers, to which non-authorized computers do not have access, and Ethernet booting of the servers is done through that network.
So the bug can be exploited only by a company insider, who must be an admin for the case with a separated management network, or by an external attacker who already has control over an internal computer, which must be the computer of an admin in the case with separate management network.
https://www.coreboot.org/
we will hopefully soon see an end to this sort of naive optimism, especially when it's an ai-assisted/ai-found vulnerability.
Instead, it applies only to organizations with machines that boot from local networks, or conceivably from Internet-connected resources.
Who is PXE-booting over the open Internet!?
https://tianocore-docs.github.io/EDKIIHttpsBootGettingStarte...
It's incredibly common though? I've run across it and I work on games and client software, not server stuff.
This shit used to confuse me so hard when I was learning security. It seemed that articles were talking about something really important, but I just couldn't connect it to anything I knew. Then I realized they weren't talking about security for users, but rather security from users - and for entities ultimately looking to restrict users (the same inversion-of-authority as TSA propaganda). Hence the syndrome of acronym hell, as that amount of overabstraction is required to motivate a system for its own purposes.
Now given that this is a network exploit, you've got to adapt my model a bit from above - my framing is most clear when talking about local "exploits" in locked down bootloaders etc. But from an individual security perspective here? If you've disabled the network stack in your BIOS (because why the hell is it there in the first place), OR put any management interfaces on their own network unreachable from anything that isn't trusted to be managing, this is an utter nothingburger.
It's Ars; you come to expect it.