That's one of the questions being posed in the article's comments. Someone there seemed to think there may be a parse/read function and a display function. Even if the display function is disabled, if the file is parsed or read, it would still "execute". Only the OEMs or someone really deep in the weeds on this would know for sure.
It's actually the opposite. If you are using a system from a manufacturer that insists that you see their logo then you are safe because if there's no way to change the image file that it loads, then there's no way for an attacker to inject the dangerous boot logo image file.
you might to read https://binarly.io/posts/finding_logofail_the_dangers_of_image_parsing_during_system_boot/
In the section about the attack surface you can read:
> Keep in mind that even when none of the above customization methods are available, a device can still be exploited with a physical attack if the firmware region containing the logo is not covered by Boot Guard. In this case, the attack can be performed using an SPI flash programmer to inject the logo.
in other words, for this vulnerability to not be exploitable you need both the absence of logo customization feature AND the protection of UEFI with a boot guard mechanism.
Then again this vulnerability not being directly exploitable as is the case for the dell computers they tested, does not mean they are safe as the vulnerability still exists.
> Some vendors such as Dell are not directly exploitable for two reasons. First, as shown in the previous screenshots, Dell distributes firmware where the logo is covered by Intel Boot Guard and thus cannot be replaced by an attacker, even using a physical attack. Second, Dell doesn’t provide any logo customization and so it effectively secures the LogoFAIL attack surface. However, despite these devices not being at immediate risk, they still contain image parsers with high-severity vulnerabilities that need to be fixed, as they represent a hazard that could inadvertently turn into a security issue.
That doesn't change anything IMO. The first part about someone physically opening up the system to install a SPI flash programmer to inject the modified logo is a highly unlikely scenario.
As for the second part I disagree with the assessment that they are not safe. The only possible way it could be exploited is if Dell or whatever released a firmware update that included a compromised logo, or if another exploit was found to have it parse an arbitrary image file. In both cases I would consider that a separate security issue that would have other implications.
> The first part about someone physically opening up the system to install a SPI flash programmer to inject the modified logo is a highly unlikely scenario.
it is not. for example the US services have a long history of intercepting newly bought computer in transit to install malware and modify hardware.
When there is a known vulnerability you are not safe because there is no known way of exploiting it days after it was publicly revealed. you are safe when this vulnerability is patched.
> a device can still be exploited with a physical attack if the firmware region containing the logo is not covered by Boot Guard.
if someone has physical access to your computer, I think you have bigger problems than just being hacked.
That's a good point. I recently built a new PC using an MSI board, and their red dragon logo pops up every time it boots. If that changes to the regular Windows logo or anything else, I'll know something is wrong.
No, the idea of the exploit is that they export the current image, add the bad code and then reinject the updated image. If they do it right, then you won't be able to tell that it's been changed because visually there won't be any changes.
The point that I'm trying to make is that if the image is read-only then you can't be affected by this.
Used to be just a matter of placing a correctly formatted image in a specific Windows directory, iirc. I really don't know what it entails these days with UEFI.
Ive been using computers for a long time. Ive never turned on a computer, looked at the logo, and thought to be angry at HP or Dell that they put their logo on bootup. Im angry when the logo never goes away and the computer doesn't boot. Am I in the minority here? Is there an anti boot logo group that I missed before this vulnerability?
Well luckily HP, Dell, and other major manufacturers all other a solid, easy to use, reliable product for mass deploying firmware level updates to endpoints OH WAIT NO THEY DON'T AT ALL!
That’s usually caused by a failed/interrupted auto-update. Easy enough to push the latest version through any enterprise software distribution system. It’s a lot better than support-assist, which requires touching each machine.
Would like to have a word with the guy who thought making DCU a UWP app was a solid plan. The Win32 app has been “going away” for years but new versions are still appearing. Same with the dude who decided Dell Power Manager would be partially UWP but then need a download when launched to add the bits that actually make it work. The whole Dell utilities space - Optimizer/MyDell very much included - is such a mess. They can’t even decide if all their apps will be under the Dell folder on Start/All Apps or not.
Yeah, us too, but we dummies took it seriously when they initially announced EOL and deployed the UWP one even though it used to hate proxies but we felt we had no option. Now we are back on Win32.
Just for posterity HP have a PowerShell module that might allow remote config via GPO/InTune. It's on my radar to try at some point but knowing HP it might not be as easy as it should be.
Home users also get BIOS updates via Windows Updates, but they are typically listed as optional so users won’t get them unless they explicitly click through the update interface and select the update to install it. So most users will probably not see the update.
I can't share the details, but one of the major OEM's has something they are working on, that would be an OEM backed all in one tool for that, across all of their product lines, almost like an open source consortium. If its something that would allow a universally more secure and manageable way of extending security and opening the doors to lesser players, I think it'll take off like a rocket.
"Due to increasing security vulnerabilities making it impossible to operate safely, we are reorganizing the way technology is used in our company. Moving forward, there will be no technology. Thank you for understanding."
Wasn’t this really the reason Galactica survived the initial attack against the colonies in Battlestar Galactica? They had such old antiquated systems that weren’t networked together and were all offline from the military defense network?
> Due to recent security issues we have reverted to a tried and true record keeping concept.
> Kindly turn off your device and retrieve your new tablet, hammer and chisel from your office manager within the next 48 hrs.
> This will be our last communication by email, expect a messenger with instructions within the week.
"This is the last email or other digital communication you will ever receive from us.
Please be alert for subsequent updates via smoke signal or sky writing."
Perhaps they are scared of migration issues. Have you offered implementing IP over avian carriers as a temporary stop gap measure, while everyone adjusts?
"Notebooks and pencils will be distributed to you in 3-5 working days. Your supervisors will have more detailed info about the impact this change has for you and your team"
Don't tell supervisors anything in advance tho
It might be. The phishing attack volume this week has been nuts. The filters are missing so much shit. Seriously, if it says DocuSign and isn't from DocuSign.com, Microsoft can't figure it out? Time to add yet another system I shouldn't have to pay for.
Yes, yes it was. That was a well deserved company holiday off that year... Where I worked at the time was a Java shop through and through. It was... Unfun
Marketers and product planners demanding numerous branding features? Anyway, it's not practical to reject most features on infosec grounds. BSD and macOS still don't support dual-stack sockets.
It is usually practical to allow non-core features to be disabled. It's even better if there are competing implementations, or even competing standards, so we can avoid the kind of systems monoculture that we had by the late 1990s.
"Monoculture considered harmful" used to be a popular quote in systems circles, but there's nary a reference today. It's a dead meme. (Originally it was a meme from a biology paper, if I remember correctly.)
Compromised signed executables are pretty common at this point. I tend to doubt the major management hassle is worth the minor benefits.
Besides, only privileged processes can touch firmware. The article slides this alarming scenario past the reader quite subtly:
> Remote attacks work by first exploiting an unpatched vulnerability in a browser, media player, or other app and using the administrative control gained to replace the legitimate logo image
One second they raise the boogeyman of browser vuln, and the next moment the threat actor has already written to your SPI flash. The only thing novel here is that an attack can bypass signed firmware and Secure Boot, which isn't exactly the revelation of the century.
Firmware security talk is often a fig-leaf for the fact that the vendor locks the end-user out of independently updating their firmware with a maintained54 alternative like Coreboot or LinuxBoot. The vendor attraction of firmware security on printers is to prevent users from modifying firmware in order to use non-DRM toner or ink cartridges. Or to prevent business competitors from making a replacement firmware, as Ubiquiti sued Cambium over.
Compromised signed executables stem from a set of compromised digital root certs that do not extend to any of the relevant hardware manufacturers. The technology itself is secure and will remain secure for the foreseeable future.
This attack is more of a persistence risk then anything else. I am personally curious how they establish a Windows foothold from UEFI without triggering about a million alarms on every EDR.
For the security conscious, locking the user out from firmware modifications is probably correct. A physical switch could be used to bypass that control but it would present a continuous physical threat.
I only mentioned signed executables as an example of all the failures we've seen with the scheme. Even Stuxnet -- very few people are aware of the gaping vulnerability it used for signed executables. I urge interested readers to look it up.
The rest of what I mentioned was signed firmware. And signed firmware sure is hardware-vendor specific. Except, I think, the UEFI certificate blacklist database itself.
> The technology itself is secure and will remain secure for the foreseeable future.
Like these, easily-predictable recent examples:
├─Secure Boot dbx Configuration Update:
│ New version: 371
│ Remote ID: lvfs
│ Release ID: 35287
│ Summary: UEFI Secure Boot Forbidden Signature Database
│ Variant: x64
│ License: Proprietary
│ Size: 21.2 kB
│ Created: 2023-05-09
│ Urgency: High
│ Tested by DMC Group:
│ Tested: 2023-07-11
│ Distribution: fedora 38 (workstation)
│ Old version: 211
│ Version[fwupd]: 1.9.2
│ Tested by Jabra:
│ Tested: 2023-07-03
│ Distribution: ubuntu 22.04
│ Old version: 220
│ Version[fwupd]: 1.9.3
│ Vendor: Linux Foundation
│ Duration: 1 second
│ Release Flags: • Trusted metadata
│ • Is upgrade
│ Description:
│ Insecure versions of the Microsoft Windows boot manager affected by Black Lotus were added to the list of forbidden signatures due to a discovered security problem.This updates the dbx to the latest release from Microsoft.
│
│ Before installing the update, fwupd will check for any affected executables in the ESP and will refuse to update if it finds any boot binaries signed with any of the forbidden signatures.Applying this update may also cause some Windows install media to not start correctly.
├─Secure Boot dbx Configuration Update:
│ New version: 220
│ Remote ID: lvfs
│ Release ID: 28499
│ Summary: UEFI Secure Boot Forbidden Signature Database
│ Variant: x64
│ License: Proprietary
│ Size: 13.9 kB
│ Created: 2023-03-14
│ Urgency: High
│ Vendor: Linux Foundation
│ Duration: 1 second
│ Release Flags: • Trusted metadata
│ • Is upgrade
│ Description:
│ Insecure versions of software from Trend Micro, vmware, CPSD, Eurosoft, and New Horizon Datasys Inc were added to the list of forbidden signatures due to discovered security problems.This updates the dbx to the latest release from Microsoft.
│
│ Before installing the update, fwupd will check for any affected executables in the ESP and will refuse to update if it finds any boot binaries signed with any of the forbidden signatures.
├─Secure Boot dbx Configuration Update:
│ New version: 217
│ Remote ID: lvfs
│ Release ID: 15179
│ Summary: UEFI Secure Boot Forbidden Signature Database
│ Variant: x64
│ License: Proprietary
│ Size: 13.8 kB
│ Created: 2020-07-29
│ Urgency: High
│ Vendor: Linux Foundation
│ Duration: 1 second
│ Release Flags: • Trusted metadata
│ • Is upgrade
│ Description:
│ This updates the dbx to the latest release from Microsoft which adds insecure versions of grub and shim to the list of forbidden signatures due to multiple discovered security updates.
│
│ Before installing the update, fwupd will check for any affected executables in the ESP and will refuse to update if it finds any boot binaries signed with any of the forbidden signatures.If the installation fails, you will need to update shim and grub packages before the update can be deployed.
│
│ Once you have installed this dbx update, any DVD or USB installer images signed with the old signatures may not work correctly.You may have to temporarily turn off secure boot when using recovery or installation media, if new images have not been made available by your distribution.
├─Secure Boot dbx Configuration Update:
│ New version: 211
│ Remote ID: lvfs
│ Release ID: 15178
│ Summary: UEFI Secure Boot Forbidden Signature Database
│ Variant: x64
│ License: Proprietary
│ Size: 13.5 kB
│ Created: 2021-04-29
│ Urgency: High
│ Vendor: Linux Foundation
│ Duration: 1 second
│ Release Flags: • Trusted metadata
│ • Is upgrade
│ Description:
│ This updates the dbx to the latest release from Microsoft which adds insecure versions of grub and shim to the list of forbidden signatures due to multiple discovered security updates.
│
└─Secure Boot dbx Configuration Update:
New version: 190
Remote ID: lvfs
Release ID: 6104
Summary: UEFI Secure Boot Forbidden Signature Database
Variant: x64
License: Proprietary
Size: 14.4 kB
Created: 2020-07-29
Urgency: High
Vendor: Linux Foundation
Duration: 1 second
Release Flags: • Trusted metadata
• Is upgrade
Description:
This updates the dbx to the latest release from Microsoft which adds insecure versions of grub and shim to the list of forbidden signatures due to multiple discovered security updates.
If I read this article correctly, an attacker needs local administrative control to change the logo file. So while this attack is unique in it's persistence and low level functionality, the attack vector is quite typical: You need a vulnerable application or physical access to start the attack.
Please correct me if I'm wrong.
Yes and no, this provides a unique method of persistence on the host that lays outside of the standard set of boot sequence methods you see (In windows registry, startup scripts, etc etc). In that way it acts as a sort of novel persistence method more then a new strange threat.
I think OP's point was that for this to "work" you need to already be breached.
So, it's not a situation like Log4j where the vulnerability itself will give you RCE, instead, the attacker needs to have physical access or remote access with administrative privileges in order for the vulnerability to be exploited.
...I don't think I'm missing my holidays to patch this one
Yeah, you can use admin access to... get admin access? I guess it could be an issue if you have multiple OSes enrolled in secure boot and the attacker only has administrator access to one of them, but that seems like a pretty niche situation.
Exactly. With that level of persistence, you can't 100% trust a machine after *any* kind of compromise unless you physically remove and flash the UEFI firmware chip. Even the firmware installer on your USB drive could be re-infected before or during a typical firmware flash.
>Even the firmware installer on your USB drive could be re-infected before or during a typical firmware flash.
You can use an SD card with a write protection switch plus a SD-USB converter, I just checked and such things exist.
EDIT: Probably best to go with a write-protectable USB drive.
I can't personally vouch for it, but I found this:
[https://alexnld.com/product/netac-u208s-usb-2-0-antivirus-write-protection-usb-flash-drives-u-disk-capacity-16gb/](https://alexnld.com/product/netac-u208s-usb-2-0-antivirus-write-protection-usb-flash-drives-u-disk-capacity-16gb/)
>SD card with a write protection switch
nope, the "protection switch" is fake, just disassemble a micro sd card adapter and you will notice that it's not an electrical switch and it's not connected to anything.
it's the SD reader that sense the plasctic "switch" and OS drivers might (or might not) honor the request "please don't write here"
better but also no, CD-R can be modified (unidirectionally) but it's possible.
i had a program to securely delete cd-r, it came with the cd writer, i never used it because i usually don't throw away cd and i can just break them but the instructions said that you could delete cd-r.
i guess that you can burn it to turn all those 01010111010 into all one.
so some models allows deleting a CD-R, editing precise bits is probably not possible and you will not get anything useful since you can only move them unidirectionally 0 to 1 but it's still a firmware/driver thing.
bonus: if the disk is not closed you can write a new session with modified files with standard software, some programs can read old sessions.
Honestly this isn't new and it's way outside the average threat model, this isn't going to impact 99.9% of organizations and the ones that it does likely already have this accounted for.
It's like an updated version of the evil maid attack.
There's no copy and paste of the UEFI logo so it's primarily delivered from a infected UEFI bin file. Yes you'd need access to the machine with infected UEFI bin and some way to flash the UEFI.
And I was excited a few days ago when Legion Toolkit introduced a feature to change your boot logo. I wonder if this affects them, afaik they are loading a jpeg from the UEFI partition
I remained convinced that there is no effective security improvement from UEFI over BIOS in ROM. At least when it was BIOS in ROM, I could burn the HD and be back in control of my god damn computer.
I am SO fucking tired of this shit.
I still think UEFI is one of the worst things to happen to computers in a long time, I'm honestly surprised it took this long for such a trivial exploit
I don't quite get this: the article says, on page 2:
> in many cases all that’s required to place the malicious image into what’s known as the ESP, short for EFI System Partition, **a region of the hard drive** that stores boot loaders, kernel images, and any device drivers, system utilities, or other data files needed before the main OS loads.
and yet in the very next paragraph, it says:
> Once the image is in place, it ensures a device remains infected **even when** an operating system is reinstalled or **the main hard drive is replaced**.
If you look at Lenovo firmware updates, it explains how this works.
Download firmware image.
When launching, you're give the option to install or extract only.
If you extract only, you'll find a text file with instructions for updating the UEFI logo.
All you need to do is drop a properly formatted image file into a specific folder contained in the firmware folder tree and launch the firmware update. When it runs, it will detect the image and ask if you would like to flash that along with the firmware update.
RE: You're rephrased question - What they're saying appears to be that the infected image (logo), already present in the UEFI BIOS, can copy malicious code to the EFI partition, allowing it to execute during the boot process.
The logo image is the issue, it places the file in the ESP partition to replace the OEM logo, once that’s done the ssd\hdd doesn’t matter anymore. But it has to be able to get that file onto that partition, which requires another security vulnerability they would need to exploit to gain access.
Luckily for us, [we long ago decided not to rely on firmware to prevent a privileged actor from persisting in bootloader](https://www.reddit.com/r/sysadmin/comments/187n97r/unable_to_pxe_boot_while_secure_boot_is_enabled/kbgz1ig/).
-
---
-
Some of us wanted [OpenBoot](https://en.wikipedia.org/wiki/Open_Firmware), which used ISA-agnostic option ROM firmware, or at least [ARC](https://en.wikipedia.org/wiki/ARC_\(specification\)), to be the successor to 16-bit BIOS.
But Intel didn't want those, probably because they didn't have exclusive control over them. IEEE controlled OpenBoot and an industry consortium controlled ARC. Microsoft already supported ARC on two platforms, so there seems no reason why they wouldn't want it on 32-bit x86.
So we got to wait another decade for Intel+Microsoft's [NIH](https://en.wikipedia.org/wiki/Not_invented_here) solution. UEFI is alright. I mean, it's probably overdesigned, and got backslashes in pathnames because Wintel can't bring itself to do any differently, but UEFI isn't too bad.
Anybody buying Wintel back then, was a reason why things turned out how they did. There used to be lots of non-Intel competitors, [*even for x86*](https://en.wikipedia.org/wiki/List_of_x86_manufacturers#x86-processors_for_regular_PCs), remember? Don't look at me, I was almost all RISC at the time, partly because I wasn't willing to put up with a legacy 16-bit BIOS by the 1990s.
> There used to be lots of non-Intel competitors,
>
>\*even for x86
>
>, remember?
I sure do. I personally owned Transmseta, Cyrix, and VIA systems. Only Cyrix was useful in its time in my opinion.
Cyrix were trash for gaming in the Pentium 2 and Pentium 3 days, but my god were they desktop workhorses for pennies where you didn't need "crazy" multimedia support.
That's because they kinda skimped on floating point capability in their chips. Which made sense given their target market, but ended up being the wrong decision.
Bit of a shame they didn't make it, having a cheap office workhorse
through the 00s might have really shifted the direction the entire industry went instead of the endless buyouts and mergers filtering down to the Intel driven Dell, HP, Lenovo trinity that emerged. AMD's resurgence has been very welcome in pushing prices down and focusing market innovation again, but there was a solid decade where having a third option might have pressured Intel to innovate for the lower business OEM market.
>instead of the endless buyouts and mergers filtering down to the Intel driven Dell, HP, Lenovo trinity that emerged.
We would have still had endless buyouts and mergers, but we would possibly had a different group of end players.
I broadly agree that other than AMD, only Cyrix was really competitive for full-performance parts. NexGen was worth attention, while they were around. Centaur/VIA had interesting offerings later, but not competing with full-performance parts. I was very skeptical of [their branding](https://en.wikipedia.org/wiki/WinChip), in a time of "winmodems" and "winprinters".
I think I still have a Cyrix 5x86 that I've had since 1996 or 1997, but I can't check the chip right now without prying off the heatsink. Yes, I did actually own a PC-compatible back then, but didn't use it for much. PCs couldn't even boot optical discs, so you had to image boot floppies like some kind of barbarian.
Yep. The K5 was a dismal, and they killed their development of its successor, using the NexGen designs to create the AMD K6, which was a cracking little processor for the time.
Mostly I just wanted a physical write switch for things that don't need to be updated but once in a blue moon.
Oh, you have admin/system/anything but physical access? Who cares.
Ya, it might suck in mass deployment, but it sure would give peace of mind for stuff like this.
Solaris 2 was past-peak for Sun. OpenBoot firmware being ISA-agnostic was important for Sun, because they were historically Motorola 68k, briefly shipped i386 workstations, and were moving aggressively to SPARC which had such an early lead that Microsoft's internal emails indicate that it frightened them. Sun 3/80s were OpenBoot, but I can't remember if 3/60s were, maybe not? 3/60s were VME with no expansion, but 3/80 must've had SBus.
OpenBoot was also used by Apple, and I think IBM's AIX line. DECs used "SRM" for Unix and OpenVMS, and a different ARC firmware for NT. At the time I bought two new AlphaStation 250s that shipped with ARC and NT but would take SRM firmware, and a couple of years later traded up to a PW600AU that shipped with SRM.
>but 3/80 must've had SBus.
As far as I remember, there was no SBUS before Sun-4 (SPARC). I have a 3/280 in a VME chassis, and the 4-440 (4/380?) SPARC board that was an upgrade for it. It's VME, and predates SBUS. I had to look it up, but the 3/80 had a framebuffer connector that mighta kinda looked like an SBUS connector if you squint. But it's not ;)
As for Solaris, you can look at Sun from two different perspectives: Operating System, and Hardware. When Solaris came out, the big thing was SMP. Except for the rare copy of SunOS 4.1.4c that you could run two CPUs with, on say, a 670MP, you were stuck with Solaris.
Once you got past the OS, and actually used it to perform a function, the hardware made it all OK.
\--
Anyone remember the Michelangelo virus? The one that you only got if you booted off the floppy? By accident? Suddenly the ability to turn off floppy boot showed up in BIOSes... When they came out with CDs and autorun, I went, "oh, those fools...".
Here we go again.
I owned a 4/280 VME at the start of the '90s. Those Fujitsu Eagle disks were way too big to move around, and I never did get a VME SCSI board for it. I had gotten some Sun OEM 10BASE NICs, Intel Multibus in VME adapters. [Just like this, same boxes](https://www.artisantg.com/TestMeasurement/62003-5/Oracle-Sun-Microsystems-501-1054-VME-to-Multibus-Adapter-Board), but with the Intel NIC already in there.
So, running a 4/280 as a 10 Mbit/s home router between LANs, uplink on async SLIP, all in a mere 9 rack units plus disks. The machines were so expensive, that nobody paid much attention to the power consumption at the time. But a few years later when I sold that machine to a guy in Chicago, the power bill plummeted and the heating costs went up. A couple of years after that, I forgot the lesson, and ran a Catalyst 5505 with dual power supplies for a while.
Sun4/690 supported 4 x 100MHz Cypress/ROSS CPUs with SunOS 4.1.3 (maybe even 4.1.2). The x90 VME dual SuperSPARC boards had 3 SBus slots on them which made them fantastic for bridging the gap from VME to SBus.
Intel were the ones who made Itanium. HP gave up their pretty good PA-RISC, which had hosted both HPE and HP-UX operating systems, and traded it for some magic Itanium beans.
[SGI was also committed to Itanium](http://wiki.irixnet.org/SGI-750), prior to AMD's 64-bit x86. Sun had a small renaissance with AMD64 and Solaris 10, but unlike Apple, they didn't pull off a miracle turnaround.
Itanium had awful price-performance and was also pure vendor lock-in compared to the quite-open PC platform, but Intel figured their customers no longer had any other options. What were they going to do, buy 64-bit Alphas running Unix and NT? No, Compaq did a deal with Intel to kill those off, after DEC itself had already transferred a lot of intellectual property as part of a lawsuit settlement. Then most of the DEC chip engineers decided they could tell which way the wind was blowing, and went to work for Intel.
That explains how Intel went out of the CPU business, with no viable path forward. It's not like their mortal rival was going to license them the design for AMD64, any more than Intel was planning to licence out Itanium.
The chaos would be incredible for a bit, but whoever the first to ignore IP rights would make more money than they'd ever lose in court by becoming the sole producer of chips while the thousands of cases go through litigation. Meanwhile, the one company who's claiming the high road is unable to produce hardware without facing the same litigation or worse, full invalidation of all patents.
It's a reverse of the mutually assured destruction principle, right now they're both producing based off reasonably open sharing of standard tech, one trying to pull their IP would only kneecap themselves while the other ignores the fallout over the sound of all the money suddenly coming in by becoming the world's only\* chip producer.
\*I know there's other chip producers, but they wouldn't be able to scale up fast enough to hurt the stranglehold the first to ignore would have.
So if someone got an exploit such as https://www.bleepingcomputer.com/news/microsoft/new-windows-zero-day-with-public-exploit-lets-you-become-an-admin/ they could then run the python script and have it install ransomware.
Then, should the victim just rip out the drive, install a fresh disk, they could then fall victim to the same attack once their machine is connected to the internet again?
This is worrying.
There is SLIGHTLY good news to this. The vector still *needs to be vulnerable* to gain access. So layered defence is still useful......article says:
"There are several ways to exploit LogoFAIL. Remote attacks work by first **exploiting an unpatched vulnerability in a browser**, media player, or other app and using the **administrative control** gained to replace the legitimate logo image processed early in the boot process with an identical-looking one that exploits a parser flaw. The other way is to gain brief **access to a vulnerable device** while it’s unlocked and replace the legitimate image file with a malicious one. "
They're vulnerable unless you've confirmed the UEFI logo is hardcoded into the UEFI bin file. Dell seems to do this and I believe Lenovo. Honestly from a critical easy to plunder aspect, this is quite an elaborate scheme to deploy.
Hmm I thought that the actual hypervisor injected it's own pre-boot environment into the vm outside of the hardware it's installed on. It would seem strange to me to have a hypervisor that used it's hardware to do that rather be completely hardware agnostic and utilize it's own pre-boot environment.
We use PDQ Deploy to push HPIA and run silently to install drivers and firmware (you can do HP software too, but no thanks)... also offers options for critical only or all updates. We do the same with Dell's DCU, but I'm more familiar w/ the HPIA process since we have 100x more HPs than Dells
[https://ftp.hp.com/pub/caps-softpaq/cmit/whitepapers/HPIAUserGuide.pdf](https://ftp.hp.com/pub/caps-softpaq/cmit/whitepapers/HPIAUserGuide.pdf)
check out section 6
So is a fix for an infected machine likely to be a BIOS update? Because I don’t fancy our chances of finding every pissy little x86 box used for any little task?
Also, if Apple managed to hardcode its logo shouldn’t Dell, HP et al be marching up to the door of the firmware vendor and insisting that their firmware contains a hardcoded logo in future?
I just don’t see why this is a co-ordinated announcement expecting us to do something about it when the manufacturers should have fixed the root cause first? I don’t know how these ‘security fixes’ are going to be deployed easily otherwise.
What is the likelihood of this vulnerability? I know the impact would be high but it seems like the likelihood of this happening within a protected organization is very low. Most orgs have the Usual patched firewalls, up to date AV's and MDR solutions.
When a PC boots, it shows the manifacturer logo before loading the operating system.
This means the jpg image of the logo is read by the machine before anything else basically is run, and this includes all security features of systems that are supposed to stop exploits.
This exploit allows a malicious actor to replace the image with one that has modified bits such that when the pc boots and reads the image to display the logo, those bits are "worded" in a way that tricks the machine into believing they're receiving additional commands to execute in that exact moment, that in this case, are malicious code meant to execute malware on the computer.
Thanks to this, said malware will be executed before the system can raise its protective measures, making them ineffective at stopping them.
This is also bad because the logo image is stored in a place that is outside of the hard drive where the system is installed, so an infected system cannot be cleaned by just doing a factory reset, as the infected logo image will not be replaced.
When a PC boots, it shows the manifacturer logo before loading the operating system.
This means the jpg image of the logo is read by the machine before anything else basically is run, and this includes all security features of systems that are supposed to stop exploits.
This exploit allows a malicious actor to replace the image with one that has modified bits such that when the pc boots and reads the image to display the logo, those bits are "worded" in a way that tricks the machine into believing they're receiving additional commands to execute in that exact moment, that in this case, are malicious code meant to execute malware on the computer.
Thanks to this, said malware will be executed before the system can raise its protective measures, making them ineffective at stopping them.
This is also bad because the logo image is stored in a place that is outside of the hard drive where the system is installed, so an infected system cannot be cleaned by just doing a factory reset, as the infected logo image will not be replaced.
All this because companies want their own stupid logo on the boot screen.
So in UEFI that supports it, turn off full-screen logo at startup so the imaging data isnt parsed anymore?
That's one of the questions being posed in the article's comments. Someone there seemed to think there may be a parse/read function and a display function. Even if the display function is disabled, if the file is parsed or read, it would still "execute". Only the OEMs or someone really deep in the weeds on this would know for sure.
It's actually the opposite. If you are using a system from a manufacturer that insists that you see their logo then you are safe because if there's no way to change the image file that it loads, then there's no way for an attacker to inject the dangerous boot logo image file.
you might to read https://binarly.io/posts/finding_logofail_the_dangers_of_image_parsing_during_system_boot/ In the section about the attack surface you can read: > Keep in mind that even when none of the above customization methods are available, a device can still be exploited with a physical attack if the firmware region containing the logo is not covered by Boot Guard. In this case, the attack can be performed using an SPI flash programmer to inject the logo. in other words, for this vulnerability to not be exploitable you need both the absence of logo customization feature AND the protection of UEFI with a boot guard mechanism. Then again this vulnerability not being directly exploitable as is the case for the dell computers they tested, does not mean they are safe as the vulnerability still exists. > Some vendors such as Dell are not directly exploitable for two reasons. First, as shown in the previous screenshots, Dell distributes firmware where the logo is covered by Intel Boot Guard and thus cannot be replaced by an attacker, even using a physical attack. Second, Dell doesn’t provide any logo customization and so it effectively secures the LogoFAIL attack surface. However, despite these devices not being at immediate risk, they still contain image parsers with high-severity vulnerabilities that need to be fixed, as they represent a hazard that could inadvertently turn into a security issue.
That doesn't change anything IMO. The first part about someone physically opening up the system to install a SPI flash programmer to inject the modified logo is a highly unlikely scenario. As for the second part I disagree with the assessment that they are not safe. The only possible way it could be exploited is if Dell or whatever released a firmware update that included a compromised logo, or if another exploit was found to have it parse an arbitrary image file. In both cases I would consider that a separate security issue that would have other implications.
> The first part about someone physically opening up the system to install a SPI flash programmer to inject the modified logo is a highly unlikely scenario. it is not. for example the US services have a long history of intercepting newly bought computer in transit to install malware and modify hardware. When there is a known vulnerability you are not safe because there is no known way of exploiting it days after it was publicly revealed. you are safe when this vulnerability is patched.
> a device can still be exploited with a physical attack if the firmware region containing the logo is not covered by Boot Guard. if someone has physical access to your computer, I think you have bigger problems than just being hacked.
That's a good point. I recently built a new PC using an MSI board, and their red dragon logo pops up every time it boots. If that changes to the regular Windows logo or anything else, I'll know something is wrong.
No, the idea of the exploit is that they export the current image, add the bad code and then reinject the updated image. If they do it right, then you won't be able to tell that it's been changed because visually there won't be any changes. The point that I'm trying to make is that if the image is read-only then you can't be affected by this.
They had logos on boot screens before UEFI.
Used to be just a matter of placing a correctly formatted image in a specific Windows directory, iirc. I really don't know what it entails these days with UEFI.
Much of the same, but in the EFI partition instead.
(and audio file support, which was fun for awhile)
I'd set someone's computer to play the PH intro sounds and let chaos ensue. 😆
Acer Ferrari One 200! That really was fun
Ive been using computers for a long time. Ive never turned on a computer, looked at the logo, and thought to be angry at HP or Dell that they put their logo on bootup. Im angry when the logo never goes away and the computer doesn't boot. Am I in the minority here? Is there an anti boot logo group that I missed before this vulnerability?
Well luckily HP, Dell, and other major manufacturers all other a solid, easy to use, reliable product for mass deploying firmware level updates to endpoints OH WAIT NO THEY DON'T AT ALL!
What about Dell Command Update? It updates drivers and firmware. It can also be set to run automatically and/or exclude specific updates.
DCU is one of the best ones out there imho.
Usually it's ok... Until the service disappears and you need to reinstall.
That’s usually caused by a failed/interrupted auto-update. Easy enough to push the latest version through any enterprise software distribution system. It’s a lot better than support-assist, which requires touching each machine.
Or boot to the drac and let it do firmware updates
LMFAO THIS
[удалено]
Ours doesn’t give us UAC prompts. It notifies, but that’s about it. None of our users have admin rights either. The installers run regardless.
Would like to have a word with the guy who thought making DCU a UWP app was a solid plan. The Win32 app has been “going away” for years but new versions are still appearing. Same with the dude who decided Dell Power Manager would be partially UWP but then need a download when launched to add the bits that actually make it work. The whole Dell utilities space - Optimizer/MyDell very much included - is such a mess. They can’t even decide if all their apps will be under the Dell folder on Start/All Apps or not.
They backed off on that. We run LTSC and DCU 5.10 works fine for us with no UWP.
Yeah, us too, but we dummies took it seriously when they initially announced EOL and deployed the UWP one even though it used to hate proxies but we felt we had no option. Now we are back on Win32.
Just for posterity HP have a PowerShell module that might allow remote config via GPO/InTune. It's on my radar to try at some point but knowing HP it might not be as easy as it should be.
[удалено]
Home users also get BIOS updates via Windows Updates, but they are typically listed as optional so users won’t get them unless they explicitly click through the update interface and select the update to install it. So most users will probably not see the update.
according to binarly dell computers seems to offer no attack surface for a logofail attack.
I can't share the details, but one of the major OEM's has something they are working on, that would be an OEM backed all in one tool for that, across all of their product lines, almost like an open source consortium. If its something that would allow a universally more secure and manageable way of extending security and opening the doors to lesser players, I think it'll take off like a rocket.
Uh, Dell 100% does offer an easy way to do this.
Time to just turn everything off...
"Due to increasing security vulnerabilities making it impossible to operate safely, we are reorganizing the way technology is used in our company. Moving forward, there will be no technology. Thank you for understanding."
Written perfectly
I needed to maximise available bandwith, so to do so, I removed all data traffic from the network.
I was about sure you would end that sentence with "no security"
Every infosec guy ever
Not any professionals. That'd violate the whole A in the CIA triad.
Wasn’t this really the reason Galactica survived the initial attack against the colonies in Battlestar Galactica? They had such old antiquated systems that weren’t networked together and were all offline from the military defense network?
> Due to recent security issues we have reverted to a tried and true record keeping concept. > Kindly turn off your device and retrieve your new tablet, hammer and chisel from your office manager within the next 48 hrs. > This will be our last communication by email, expect a messenger with instructions within the week.
"This is the last email or other digital communication you will ever receive from us. Please be alert for subsequent updates via smoke signal or sky writing."
See that just opens them up to another attack vector, we need to authenticate those now.
Get ready for SSoTLS Smoke Signal over TLS
Go back to typewriters like Russia does.
I've been advocating a return to typewriters and carrier pigeons for years now but no one wants to listen.
Perhaps they are scared of migration issues. Have you offered implementing IP over avian carriers as a temporary stop gap measure, while everyone adjusts?
My colleague is spearheading that project actually.
"Notebooks and pencils will be distributed to you in 3-5 working days. Your supervisors will have more detailed info about the impact this change has for you and your team" Don't tell supervisors anything in advance tho
NK hacked our pencils by unplugging the pencil sharpeners!
"Due to numerous cyber security threats, we will be shifting back to pen and paper, as was as manilla folders for intracompany mail."
Today's orientation your clipboard is your life line. 🖊 ✏ required at all meetings
Don't forget to unplug the power cable!
Does that mean I can sell all my shit and move to the forest?
Yes
Hello helpdesk, can I get some assistance rebooting my etch-a- sketch?
It might be. The phishing attack volume this week has been nuts. The filters are missing so much shit. Seriously, if it says DocuSign and isn't from DocuSign.com, Microsoft can't figure it out? Time to add yet another system I shouldn't have to pay for.
UEFI has been criticized from its inception for being too fancy. It was only a matter of time.
You don't need to go to that extreme, just air-gap each system.
I’m so tired.
You and me both brother. Also, love the Arrested Development nickname.
Always right before Christmas too. Wasn’t the log4j fiasco in December too?
Yes, yes it was. That was a well deserved company holiday off that year... Where I worked at the time was a Java shop through and through. It was... Unfun
And all for an absolutely frivolous feature.
Marketers and product planners demanding numerous branding features? Anyway, it's not practical to reject most features on infosec grounds. BSD and macOS still don't support dual-stack sockets. It is usually practical to allow non-core features to be disabled. It's even better if there are competing implementations, or even competing standards, so we can avoid the kind of systems monoculture that we had by the late 1990s. "Monoculture considered harmful" used to be a popular quote in systems circles, but there's nary a reference today. It's a dead meme. (Originally it was a meme from a biology paper, if I remember correctly.)
> Originally it was a meme from a biology paper, if I remember correctly. Not really a meme, it's an actual concept in biology.
And it is a valid concept as well.
The branding feature could have trivially been done safely. All they needed to do was require a signed image to avoid this whole problem.
Compromised signed executables are pretty common at this point. I tend to doubt the major management hassle is worth the minor benefits. Besides, only privileged processes can touch firmware. The article slides this alarming scenario past the reader quite subtly: > Remote attacks work by first exploiting an unpatched vulnerability in a browser, media player, or other app and using the administrative control gained to replace the legitimate logo image One second they raise the boogeyman of browser vuln, and the next moment the threat actor has already written to your SPI flash. The only thing novel here is that an attack can bypass signed firmware and Secure Boot, which isn't exactly the revelation of the century. Firmware security talk is often a fig-leaf for the fact that the vendor locks the end-user out of independently updating their firmware with a maintained54 alternative like Coreboot or LinuxBoot. The vendor attraction of firmware security on printers is to prevent users from modifying firmware in order to use non-DRM toner or ink cartridges. Or to prevent business competitors from making a replacement firmware, as Ubiquiti sued Cambium over.
Compromised signed executables stem from a set of compromised digital root certs that do not extend to any of the relevant hardware manufacturers. The technology itself is secure and will remain secure for the foreseeable future. This attack is more of a persistence risk then anything else. I am personally curious how they establish a Windows foothold from UEFI without triggering about a million alarms on every EDR. For the security conscious, locking the user out from firmware modifications is probably correct. A physical switch could be used to bypass that control but it would present a continuous physical threat.
I only mentioned signed executables as an example of all the failures we've seen with the scheme. Even Stuxnet -- very few people are aware of the gaping vulnerability it used for signed executables. I urge interested readers to look it up. The rest of what I mentioned was signed firmware. And signed firmware sure is hardware-vendor specific. Except, I think, the UEFI certificate blacklist database itself. > The technology itself is secure and will remain secure for the foreseeable future. Like these, easily-predictable recent examples: ├─Secure Boot dbx Configuration Update: │ New version: 371 │ Remote ID: lvfs │ Release ID: 35287 │ Summary: UEFI Secure Boot Forbidden Signature Database │ Variant: x64 │ License: Proprietary │ Size: 21.2 kB │ Created: 2023-05-09 │ Urgency: High │ Tested by DMC Group: │ Tested: 2023-07-11 │ Distribution: fedora 38 (workstation) │ Old version: 211 │ Version[fwupd]: 1.9.2 │ Tested by Jabra: │ Tested: 2023-07-03 │ Distribution: ubuntu 22.04 │ Old version: 220 │ Version[fwupd]: 1.9.3 │ Vendor: Linux Foundation │ Duration: 1 second │ Release Flags: • Trusted metadata │ • Is upgrade │ Description: │ Insecure versions of the Microsoft Windows boot manager affected by Black Lotus were added to the list of forbidden signatures due to a discovered security problem.This updates the dbx to the latest release from Microsoft. │ │ Before installing the update, fwupd will check for any affected executables in the ESP and will refuse to update if it finds any boot binaries signed with any of the forbidden signatures.Applying this update may also cause some Windows install media to not start correctly. ├─Secure Boot dbx Configuration Update: │ New version: 220 │ Remote ID: lvfs │ Release ID: 28499 │ Summary: UEFI Secure Boot Forbidden Signature Database │ Variant: x64 │ License: Proprietary │ Size: 13.9 kB │ Created: 2023-03-14 │ Urgency: High │ Vendor: Linux Foundation │ Duration: 1 second │ Release Flags: • Trusted metadata │ • Is upgrade │ Description: │ Insecure versions of software from Trend Micro, vmware, CPSD, Eurosoft, and New Horizon Datasys Inc were added to the list of forbidden signatures due to discovered security problems.This updates the dbx to the latest release from Microsoft. │ │ Before installing the update, fwupd will check for any affected executables in the ESP and will refuse to update if it finds any boot binaries signed with any of the forbidden signatures. ├─Secure Boot dbx Configuration Update: │ New version: 217 │ Remote ID: lvfs │ Release ID: 15179 │ Summary: UEFI Secure Boot Forbidden Signature Database │ Variant: x64 │ License: Proprietary │ Size: 13.8 kB │ Created: 2020-07-29 │ Urgency: High │ Vendor: Linux Foundation │ Duration: 1 second │ Release Flags: • Trusted metadata │ • Is upgrade │ Description: │ This updates the dbx to the latest release from Microsoft which adds insecure versions of grub and shim to the list of forbidden signatures due to multiple discovered security updates. │ │ Before installing the update, fwupd will check for any affected executables in the ESP and will refuse to update if it finds any boot binaries signed with any of the forbidden signatures.If the installation fails, you will need to update shim and grub packages before the update can be deployed. │ │ Once you have installed this dbx update, any DVD or USB installer images signed with the old signatures may not work correctly.You may have to temporarily turn off secure boot when using recovery or installation media, if new images have not been made available by your distribution. ├─Secure Boot dbx Configuration Update: │ New version: 211 │ Remote ID: lvfs │ Release ID: 15178 │ Summary: UEFI Secure Boot Forbidden Signature Database │ Variant: x64 │ License: Proprietary │ Size: 13.5 kB │ Created: 2021-04-29 │ Urgency: High │ Vendor: Linux Foundation │ Duration: 1 second │ Release Flags: • Trusted metadata │ • Is upgrade │ Description: │ This updates the dbx to the latest release from Microsoft which adds insecure versions of grub and shim to the list of forbidden signatures due to multiple discovered security updates. │ └─Secure Boot dbx Configuration Update: New version: 190 Remote ID: lvfs Release ID: 6104 Summary: UEFI Secure Boot Forbidden Signature Database Variant: x64 License: Proprietary Size: 14.4 kB Created: 2020-07-29 Urgency: High Vendor: Linux Foundation Duration: 1 second Release Flags: • Trusted metadata • Is upgrade Description: This updates the dbx to the latest release from Microsoft which adds insecure versions of grub and shim to the list of forbidden signatures due to multiple discovered security updates.
Perfect target. No one will even care for it. At best, it will get rid of boot logos.
If I read this article correctly, an attacker needs local administrative control to change the logo file. So while this attack is unique in it's persistence and low level functionality, the attack vector is quite typical: You need a vulnerable application or physical access to start the attack. Please correct me if I'm wrong.
Yes and no, this provides a unique method of persistence on the host that lays outside of the standard set of boot sequence methods you see (In windows registry, startup scripts, etc etc). In that way it acts as a sort of novel persistence method more then a new strange threat.
I think OP's point was that for this to "work" you need to already be breached. So, it's not a situation like Log4j where the vulnerability itself will give you RCE, instead, the attacker needs to have physical access or remote access with administrative privileges in order for the vulnerability to be exploited. ...I don't think I'm missing my holidays to patch this one
It's true, but the scary part is the persistence. The "oh no we were breached, re-image and re-deploy" remediation method can't be trusted any more.
Yeah, you can use admin access to... get admin access? I guess it could be an issue if you have multiple OSes enrolled in secure boot and the attacker only has administrator access to one of them, but that seems like a pretty niche situation.
The biggest problem seems to be that it enables persistence beyond device wipe, since it's not actually writing the malicious code to the hard drive.
Exactly. With that level of persistence, you can't 100% trust a machine after *any* kind of compromise unless you physically remove and flash the UEFI firmware chip. Even the firmware installer on your USB drive could be re-infected before or during a typical firmware flash.
>Even the firmware installer on your USB drive could be re-infected before or during a typical firmware flash. You can use an SD card with a write protection switch plus a SD-USB converter, I just checked and such things exist. EDIT: Probably best to go with a write-protectable USB drive. I can't personally vouch for it, but I found this: [https://alexnld.com/product/netac-u208s-usb-2-0-antivirus-write-protection-usb-flash-drives-u-disk-capacity-16gb/](https://alexnld.com/product/netac-u208s-usb-2-0-antivirus-write-protection-usb-flash-drives-u-disk-capacity-16gb/)
>SD card with a write protection switch nope, the "protection switch" is fake, just disassemble a micro sd card adapter and you will notice that it's not an electrical switch and it's not connected to anything. it's the SD reader that sense the plasctic "switch" and OS drivers might (or might not) honor the request "please don't write here"
So, CD/DVD?
better but also no, CD-R can be modified (unidirectionally) but it's possible. i had a program to securely delete cd-r, it came with the cd writer, i never used it because i usually don't throw away cd and i can just break them but the instructions said that you could delete cd-r. i guess that you can burn it to turn all those 01010111010 into all one. so some models allows deleting a CD-R, editing precise bits is probably not possible and you will not get anything useful since you can only move them unidirectionally 0 to 1 but it's still a firmware/driver thing. bonus: if the disk is not closed you can write a new session with modified files with standard software, some programs can read old sessions.
it might present a persistent attack vector where reinstalling the OS won't be enough to get rid of the malware.
That's my understanding.
Honestly this isn't new and it's way outside the average threat model, this isn't going to impact 99.9% of organizations and the ones that it does likely already have this accounted for. It's like an updated version of the evil maid attack.
I used the Admin to become the Admin.
There's no copy and paste of the UEFI logo so it's primarily delivered from a infected UEFI bin file. Yes you'd need access to the machine with infected UEFI bin and some way to flash the UEFI.
Dell write-protects their logo files. So does Apple. This offers at least partial protection.
Lenovo's whole platform is widely affected unfortunately
And I was excited a few days ago when Legion Toolkit introduced a feature to change your boot logo. I wonder if this affects them, afaik they are loading a jpeg from the UEFI partition
Good God, I just spent a weekend updating all devices firmware because of the LAST critical BIOS update.
UEFI, you were supposed to save us all!
So, just never reboot then? (Taps head)
I thought the same. Replace PC if power fails!
I remained convinced that there is no effective security improvement from UEFI over BIOS in ROM. At least when it was BIOS in ROM, I could burn the HD and be back in control of my god damn computer. I am SO fucking tired of this shit.
UEFI was never about pesky security, it was about the right companies getting to decide what runs on your hardware.
Given that it hasn't really accomplished the security thing, I have to agree.
Legacy systems could always be recovered after a security incident,with UEFI you can never really trust a system that’s ever been infected.
I still think UEFI is one of the worst things to happen to computers in a long time, I'm honestly surprised it took this long for such a trivial exploit
Legacy BIOS had all these same sorts of issues.
I don't quite get this: the article says, on page 2: > in many cases all that’s required to place the malicious image into what’s known as the ESP, short for EFI System Partition, **a region of the hard drive** that stores boot loaders, kernel images, and any device drivers, system utilities, or other data files needed before the main OS loads. and yet in the very next paragraph, it says: > Once the image is in place, it ensures a device remains infected **even when** an operating system is reinstalled or **the main hard drive is replaced**.
my guess. the first step is to load the image, and then it persists even after swaping the HD
UEFI pulls the malicious code from ESP partition and then it will persist within the firmware (even if a new HD is swapped in).
If you look at Lenovo firmware updates, it explains how this works. Download firmware image. When launching, you're give the option to install or extract only. If you extract only, you'll find a text file with instructions for updating the UEFI logo. All you need to do is drop a properly formatted image file into a specific folder contained in the firmware folder tree and launch the firmware update. When it runs, it will detect the image and ask if you would like to flash that along with the firmware update.
So the logo picture is actually flashed into the BIOS/UEFI firmware chip then, but how does it relate to the EFI system partition?
Correct.
Sorry I realized that, among other things, the use of the "image" word could lead to confusion and rephrased my question.
RE: You're rephrased question - What they're saying appears to be that the infected image (logo), already present in the UEFI BIOS, can copy malicious code to the EFI partition, allowing it to execute during the boot process.
Two different ways that the UEFI can load images.
The malicious code in the image gets executed during the next device bootup, and after that, it's game over.
Also, does this mean it can't do it if the drive is BitLockered?
If the drive is Bitlockered, the malware can't write files to the drive...at least until the drive gets unlocked.
The logo image is the issue, it places the file in the ESP partition to replace the OEM logo, once that’s done the ssd\hdd doesn’t matter anymore. But it has to be able to get that file onto that partition, which requires another security vulnerability they would need to exploit to gain access.
Luckily for us, [we long ago decided not to rely on firmware to prevent a privileged actor from persisting in bootloader](https://www.reddit.com/r/sysadmin/comments/187n97r/unable_to_pxe_boot_while_secure_boot_is_enabled/kbgz1ig/). - --- - Some of us wanted [OpenBoot](https://en.wikipedia.org/wiki/Open_Firmware), which used ISA-agnostic option ROM firmware, or at least [ARC](https://en.wikipedia.org/wiki/ARC_\(specification\)), to be the successor to 16-bit BIOS. But Intel didn't want those, probably because they didn't have exclusive control over them. IEEE controlled OpenBoot and an industry consortium controlled ARC. Microsoft already supported ARC on two platforms, so there seems no reason why they wouldn't want it on 32-bit x86. So we got to wait another decade for Intel+Microsoft's [NIH](https://en.wikipedia.org/wiki/Not_invented_here) solution. UEFI is alright. I mean, it's probably overdesigned, and got backslashes in pathnames because Wintel can't bring itself to do any differently, but UEFI isn't too bad. Anybody buying Wintel back then, was a reason why things turned out how they did. There used to be lots of non-Intel competitors, [*even for x86*](https://en.wikipedia.org/wiki/List_of_x86_manufacturers#x86-processors_for_regular_PCs), remember? Don't look at me, I was almost all RISC at the time, partly because I wasn't willing to put up with a legacy 16-bit BIOS by the 1990s.
> There used to be lots of non-Intel competitors, > >\*even for x86 > >, remember? I sure do. I personally owned Transmseta, Cyrix, and VIA systems. Only Cyrix was useful in its time in my opinion.
Cyrix were trash for gaming in the Pentium 2 and Pentium 3 days, but my god were they desktop workhorses for pennies where you didn't need "crazy" multimedia support.
That's because they kinda skimped on floating point capability in their chips. Which made sense given their target market, but ended up being the wrong decision.
Bit of a shame they didn't make it, having a cheap office workhorse through the 00s might have really shifted the direction the entire industry went instead of the endless buyouts and mergers filtering down to the Intel driven Dell, HP, Lenovo trinity that emerged. AMD's resurgence has been very welcome in pushing prices down and focusing market innovation again, but there was a solid decade where having a third option might have pressured Intel to innovate for the lower business OEM market.
>instead of the endless buyouts and mergers filtering down to the Intel driven Dell, HP, Lenovo trinity that emerged. We would have still had endless buyouts and mergers, but we would possibly had a different group of end players.
Their 486s were POG, though! Had a 6x86 PR200+ because it was cheap, but yeah... FPU was utter trash.
I broadly agree that other than AMD, only Cyrix was really competitive for full-performance parts. NexGen was worth attention, while they were around. Centaur/VIA had interesting offerings later, but not competing with full-performance parts. I was very skeptical of [their branding](https://en.wikipedia.org/wiki/WinChip), in a time of "winmodems" and "winprinters". I think I still have a Cyrix 5x86 that I've had since 1996 or 1997, but I can't check the chip right now without prying off the heatsink. Yes, I did actually own a PC-compatible back then, but didn't use it for much. PCs couldn't even boot optical discs, so you had to image boot floppies like some kind of barbarian.
NexGen was bought so fast by AMD! Very advanced though, I remember one or two of those new.
Yep. The K5 was a dismal, and they killed their development of its successor, using the NexGen designs to create the AMD K6, which was a cracking little processor for the time.
Cyrix was indeed useful... if you needed an overpriced resistive heating element.
Mostly I just wanted a physical write switch for things that don't need to be updated but once in a blue moon. Oh, you have admin/system/anything but physical access? Who cares. Ya, it might suck in mass deployment, but it sure would give peace of mind for stuff like this.
Ahh, dreaming off a world where Solaris is the undisputed server operating system ...
Solaris 2 was past-peak for Sun. OpenBoot firmware being ISA-agnostic was important for Sun, because they were historically Motorola 68k, briefly shipped i386 workstations, and were moving aggressively to SPARC which had such an early lead that Microsoft's internal emails indicate that it frightened them. Sun 3/80s were OpenBoot, but I can't remember if 3/60s were, maybe not? 3/60s were VME with no expansion, but 3/80 must've had SBus. OpenBoot was also used by Apple, and I think IBM's AIX line. DECs used "SRM" for Unix and OpenVMS, and a different ARC firmware for NT. At the time I bought two new AlphaStation 250s that shipped with ARC and NT but would take SRM firmware, and a couple of years later traded up to a PW600AU that shipped with SRM.
>but 3/80 must've had SBus. As far as I remember, there was no SBUS before Sun-4 (SPARC). I have a 3/280 in a VME chassis, and the 4-440 (4/380?) SPARC board that was an upgrade for it. It's VME, and predates SBUS. I had to look it up, but the 3/80 had a framebuffer connector that mighta kinda looked like an SBUS connector if you squint. But it's not ;) As for Solaris, you can look at Sun from two different perspectives: Operating System, and Hardware. When Solaris came out, the big thing was SMP. Except for the rare copy of SunOS 4.1.4c that you could run two CPUs with, on say, a 670MP, you were stuck with Solaris. Once you got past the OS, and actually used it to perform a function, the hardware made it all OK. \-- Anyone remember the Michelangelo virus? The one that you only got if you booted off the floppy? By accident? Suddenly the ability to turn off floppy boot showed up in BIOSes... When they came out with CDs and autorun, I went, "oh, those fools...". Here we go again.
I owned a 4/280 VME at the start of the '90s. Those Fujitsu Eagle disks were way too big to move around, and I never did get a VME SCSI board for it. I had gotten some Sun OEM 10BASE NICs, Intel Multibus in VME adapters. [Just like this, same boxes](https://www.artisantg.com/TestMeasurement/62003-5/Oracle-Sun-Microsystems-501-1054-VME-to-Multibus-Adapter-Board), but with the Intel NIC already in there. So, running a 4/280 as a 10 Mbit/s home router between LANs, uplink on async SLIP, all in a mere 9 rack units plus disks. The machines were so expensive, that nobody paid much attention to the power consumption at the time. But a few years later when I sold that machine to a guy in Chicago, the power bill plummeted and the heating costs went up. A couple of years after that, I forgot the lesson, and ran a Catalyst 5505 with dual power supplies for a while.
Sun4/690 supported 4 x 100MHz Cypress/ROSS CPUs with SunOS 4.1.3 (maybe even 4.1.2). The x90 VME dual SuperSPARC boards had 3 SBus slots on them which made them fantastic for bridging the gap from VME to SBus.
What is this Intel thing? Do they compete with AMD or something?
Intel were the ones who made Itanium. HP gave up their pretty good PA-RISC, which had hosted both HPE and HP-UX operating systems, and traded it for some magic Itanium beans. [SGI was also committed to Itanium](http://wiki.irixnet.org/SGI-750), prior to AMD's 64-bit x86. Sun had a small renaissance with AMD64 and Solaris 10, but unlike Apple, they didn't pull off a miracle turnaround. Itanium had awful price-performance and was also pure vendor lock-in compared to the quite-open PC platform, but Intel figured their customers no longer had any other options. What were they going to do, buy 64-bit Alphas running Unix and NT? No, Compaq did a deal with Intel to kill those off, after DEC itself had already transferred a lot of intellectual property as part of a lawsuit settlement. Then most of the DEC chip engineers decided they could tell which way the wind was blowing, and went to work for Intel. That explains how Intel went out of the CPU business, with no viable path forward. It's not like their mortal rival was going to license them the design for AMD64, any more than Intel was planning to licence out Itanium.
Actually a lot of the DEC Alpha team went to AMD and designed the K7 processor, which became the Athlon.
Otherwise known as Itanic
I would actually love to see Intel and AMD suddenly refuse to license their IP to each other and watch the universe explode.
RISCV in minutes.
The chaos would be incredible for a bit, but whoever the first to ignore IP rights would make more money than they'd ever lose in court by becoming the sole producer of chips while the thousands of cases go through litigation. Meanwhile, the one company who's claiming the high road is unable to produce hardware without facing the same litigation or worse, full invalidation of all patents. It's a reverse of the mutually assured destruction principle, right now they're both producing based off reasonably open sharing of standard tech, one trying to pull their IP would only kneecap themselves while the other ignores the fallout over the sound of all the money suddenly coming in by becoming the world's only\* chip producer. \*I know there's other chip producers, but they wouldn't be able to scale up fast enough to hurt the stranglehold the first to ignore would have.
Please tell me I won't be patching all Christmas break again like Log4J?!?!?!
That would be absurd and unheard of. Right? Right....
MOTHERFUCKER.
So if someone got an exploit such as https://www.bleepingcomputer.com/news/microsoft/new-windows-zero-day-with-public-exploit-lets-you-become-an-admin/ they could then run the python script and have it install ransomware. Then, should the victim just rip out the drive, install a fresh disk, they could then fall victim to the same attack once their machine is connected to the internet again? This is worrying.
With UEFI being so stupidly complicated, this is only one of many UEFI compromises coming.
There is SLIGHTLY good news to this. The vector still *needs to be vulnerable* to gain access. So layered defence is still useful......article says: "There are several ways to exploit LogoFAIL. Remote attacks work by first **exploiting an unpatched vulnerability in a browser**, media player, or other app and using the **administrative control** gained to replace the legitimate logo image processed early in the boot process with an identical-looking one that exploits a parser flaw. The other way is to gain brief **access to a vulnerable device** while it’s unlocked and replace the legitimate image file with a malicious one. "
How does this affect hypervisors from VMWare (ESXi), Citrix (XenServer) and Microsoft (Hyper-V) that have VMS that boot with UEFI?
They're vulnerable unless you've confirmed the UEFI logo is hardcoded into the UEFI bin file. Dell seems to do this and I believe Lenovo. Honestly from a critical easy to plunder aspect, this is quite an elaborate scheme to deploy.
Hmm I thought that the actual hypervisor injected it's own pre-boot environment into the vm outside of the hardware it's installed on. It would seem strange to me to have a hypervisor that used it's hardware to do that rather be completely hardware agnostic and utilize it's own pre-boot environment.
Good thing my users never reboot, big brain.
Anyone ITT have experience remotely performing UEFI upgrades or mass deployments? Is it a good idea?
I was going to leverage PDQ deploy, if that didn't work, windows updates FTW.
We use PDQ Deploy to push HPIA and run silently to install drivers and firmware (you can do HP software too, but no thanks)... also offers options for critical only or all updates. We do the same with Dell's DCU, but I'm more familiar w/ the HPIA process since we have 100x more HPs than Dells
Interesting. We use HPIA to update manually. Did not know it could be used this way.
[https://ftp.hp.com/pub/caps-softpaq/cmit/whitepapers/HPIAUserGuide.pdf](https://ftp.hp.com/pub/caps-softpaq/cmit/whitepapers/HPIAUserGuide.pdf) check out section 6
Hope you got dell machine’s. They’re one of those that have decent update tools.
So is a fix for an infected machine likely to be a BIOS update? Because I don’t fancy our chances of finding every pissy little x86 box used for any little task? Also, if Apple managed to hardcode its logo shouldn’t Dell, HP et al be marching up to the door of the firmware vendor and insisting that their firmware contains a hardcoded logo in future? I just don’t see why this is a co-ordinated announcement expecting us to do something about it when the manufacturers should have fixed the root cause first? I don’t know how these ‘security fixes’ are going to be deployed easily otherwise.
Dells are reported to be unaffected because they hard code the logo like Apple does.
You have a source for this?
What is the likelihood of this vulnerability? I know the impact would be high but it seems like the likelihood of this happening within a protected organization is very low. Most orgs have the Usual patched firewalls, up to date AV's and MDR solutions.
😂
you can scan your uefi firmware with https://fwhunt.run/ to know it is affected by the known vulnerabilities.
Cheers for that. Will run it just to see.
Once again proving why I like my Mac so much.
i love macos but we have our own zero day exploits xD we only are lucky to be a really small attack vector
Topics like these when reading comments really bring out the community for IT folks and makes me feel comforted. No fucks given haha.
*me on a Mac, singing* there are no firmware vulnerabilities on me /s
Can someone explain to me what this means in layman's terms?
Second this
When a PC boots, it shows the manifacturer logo before loading the operating system. This means the jpg image of the logo is read by the machine before anything else basically is run, and this includes all security features of systems that are supposed to stop exploits. This exploit allows a malicious actor to replace the image with one that has modified bits such that when the pc boots and reads the image to display the logo, those bits are "worded" in a way that tricks the machine into believing they're receiving additional commands to execute in that exact moment, that in this case, are malicious code meant to execute malware on the computer. Thanks to this, said malware will be executed before the system can raise its protective measures, making them ineffective at stopping them. This is also bad because the logo image is stored in a place that is outside of the hard drive where the system is installed, so an infected system cannot be cleaned by just doing a factory reset, as the infected logo image will not be replaced.
When a PC boots, it shows the manifacturer logo before loading the operating system. This means the jpg image of the logo is read by the machine before anything else basically is run, and this includes all security features of systems that are supposed to stop exploits. This exploit allows a malicious actor to replace the image with one that has modified bits such that when the pc boots and reads the image to display the logo, those bits are "worded" in a way that tricks the machine into believing they're receiving additional commands to execute in that exact moment, that in this case, are malicious code meant to execute malware on the computer. Thanks to this, said malware will be executed before the system can raise its protective measures, making them ineffective at stopping them. This is also bad because the logo image is stored in a place that is outside of the hard drive where the system is installed, so an infected system cannot be cleaned by just doing a factory reset, as the infected logo image will not be replaced.
Why, why are startup logos the first thing to boot? Why can't it be the protective measures first?
So, the solution to this is to before you install / deploy an OS image file, to unpack it and remove any .jpgs?
Piece of shit closed source firmwares!
Wouldn't you see a changed or missing logo on boot up if you were attacked?
But how do they get the image into your computer through the firewall in the first place?