[HN Gopher] LogoFAIL: Secure Boot bypass with manipulated boot l...
___________________________________________________________________
LogoFAIL: Secure Boot bypass with manipulated boot logos
Author : skilled
Score : 64 points
Date : 2023-12-04 10:14 UTC (2 days ago)
(HTM) web link (binarly.io)
(TXT) w3m dump (binarly.io)
| Kim_Bruning wrote:
| Who knew that non-free UEFI might be a bad idea? /s
| retrochameleon wrote:
| What do you mean?
| somat wrote:
| The really neat thing about having the source code. Is that
| it implies that you have the tool chain to build that source
| code. This is not always true, However because the source is
| mostly useless without a way to build it, it is mostly true.
| With the unfortunate note that firmware often has a nasty
| lovecraftian inspired toolchain.
|
| Once you have the source and the toolchain to build it. Now,
| not only are you in a position to fix your own bugs, all
| users of that hardware are in a position where they can co-
| operate to fix and share updates. Security update could be
| provided forever if people are willing to work on the
| problem. Having opensource firmware is a great enabler.
|
| The neat side effect of open source development is that it
| usually ends up taming the unholy tangle that proprietary
| toolchains end up becoming. Something, something.. mumble...
| about how when random joe is expected to compile a project
| that project starts shifting into a form that random joe can
| compile.
| jopsen wrote:
| > Something, something.. mumble... about how when random
| joe is expected to compile a project that project starts
| shifting into a form that random joe can compile.
|
| It's amazing what a little sunlight can do :)
| nine_k wrote:
| It seems that running anything for what you don't have source
| code becomes more and more of a liability. Not enough eyeballs,
| fuzzers, white-hat cracking attempts means a lot of serious
| risk.
| joombaga wrote:
| Is this completely mitigated by disabling boot logos?
|
| Edit: What I mean is, do the image parsers still run if boot
| logos are disabled?
| nine_k wrote:
| > _Image parsers in UEFIs from all three major IBVs are riddled
| with roughly a dozen critical vulnerabilities_
|
| I'd suspect that an image parser is only involved when a logo
| needs to be displayed. So it looks like a great way to lower
| the chances of triggering these vulnerabilities. I'll switch
| off mine.
|
| OTOH if an image parser is also invoked when the logo is
| updated, to check that it parses correctly, this won't be
| enough :(
| roywiggins wrote:
| I guess I wouldn't be surprised at all if some BIOSes always
| parse the logo and the switch just turns off the display.
| hollerith wrote:
| No because an attacker who got control could undisable them,
| then become persistently entrenched in your system such that
| you remain compromised even if you reinstall your OS.
| joombaga wrote:
| Right. I was more curious about if the image parsing code was
| still vulnerable while boot logos are disabled.
| hollerith wrote:
| Oh, you mean disabled in the motherboard's firmware
| settings. I hadn't consider that interpretation of your
| question.
|
| ADDED. I disabled it in my ASUS motherboard's settings.
| yunohn wrote:
| I wasn't aware that one could just copy paste and replace
| arbitrary UEFI boot files from user space? I was under the
| impression that they are in non-mounted partitions controlled by
| the system.
| airhangerf15 wrote:
| You can comment out /boot/efi on Linux from the fstab, and only
| mount it when you need to run a grub update. I'm not sure which
| Linux systems keep it mounted by default (I suspect most of
| them do, mostly for grub updates)
|
| I don't think Windows mounts it by default anywhere. At the
| same time, on Windows or Linux, you would need
| root/Administrator access to inject this, wouldn't you? You
| could inject any binary.
|
| I guess the thing here is that if you just replace the
| bootloader, secure boot should stop the boot process with your
| unsigned binary. With this exploit, you can replace the logo
| and it doesn't do the same signature check?
| yjftsjthsd-h wrote:
| > I guess the thing here is that if you just replace the
| bootloader, secure boot should stop the boot process with
| your unsigned binary. With this exploit, you can replace the
| logo and it doesn't do the same signature check?
|
| Exactly; most vendors apparently check signatures on anything
| officially executable but will blindly load any picture you
| hand them.
| yunohn wrote:
| But you would need sudo access to create a malicious
| bootloader partition and edit fstab. And indeed on Windows,
| I've never seen the bootloader mounted.
|
| Maybe I'm missing something in the disclosure?
| beeboobaa wrote:
| You can just write to the disk as administrator on windows.
| No need to mount anything though you could probably do that
| too.
| ikekkdcjkfke wrote:
| How nice that asking for indiscriminate admin access is a
| must to install most programs
|
| Installer: Hey, can i create a folder in Program Files?
|
| Windows: _nuclear launch codes_
| gunapologist99 wrote:
| How are you going to admin a Linux system without sudo or
| doas? (and even if you're protecting it with a password,
| the script can just silently wait and keep trying)
| pjc50 wrote:
| Does this successfully bypass "secure" boot? Quite a big deal if
| true.
|
| On the other hand now I know it's possible I'm tempted to replace
| my boot logo with a custom one..
| nine_k wrote:
| Yes :(
|
| > _The following video demonstrates a proof-of-concept exploit
| created by the researchers. The infected device--a Gen 2 Lenovo
| ThinkCentre M70s running an 11th-Gen Intel Core with a UEFI
| released in June--runs standard firmware defenses, including
| Secure Boot and Intel Boot Guard._
|
| Just checked; my laptop mounts /sys/firmware/efi/efivars and
| /boot/efi rw by default. Time to fix this. Not a huge defense
| against an RCE + priv escalation somewhere, but at least would
| help against fat fingers under sudo.
| notabee wrote:
| Poettering is very convinced that this is not a bug.
|
| https://news.ycombinator.com/item?id=11008771
|
| https://github.com/systemd/systemd/issues/2402
| nine_k wrote:
| I've read the second thread today.
|
| I'm running a "Poettering-free" distro (Void Linux), but it
| does not have this mitigation either.
| jeroenhd wrote:
| The way UEFI loads image files differs per firmware (and
| sometimes firmware version). On some devices all you need to
| do is drop a LOGO\Logo.bmp file into the ESP, on others you
| need to flash a modified firmware image. The latter requires
| a lot more permissions than the former, of course, and with
| firmware downgrade protection, flash-based attacked should
| only work right after a new firmware has been released (or if
| you choose not to update your firmware for whatever reason).
|
| The authors seem to imply that there are semi-standard ways
| of loading user-supplied images in UEFI firmware, and I'm
| kind of interested in how they achieve this without
| reflashing the motherboard's firmware.
| Voultapher wrote:
| I'm shocked!
|
| Firmware vendors, _the_ last bastion of high quality memory-safe
| C code, solving complex problems. Code firmly audited and
| formally verified to the highest degree. And now you tell me
| these people, with the highest known software quality got
| "parsing image formats" wrong?
|
| It's truly zebras all the way down https://youtu.be/fE2KDzZaxvE
| seemaze wrote:
| Thank you for that reference. As someone outside of tech, I
| still found Bryan Cantrill's presentation to thoroughly
| engaging and entertaining.
| kbenson wrote:
| You'd enjoy most his talks, even if you don't understand the
| source material. They're half anecdotes and bashing Oracle in
| a very entertaining way.
| pwdisswordfishc wrote:
| I fear your sarcasm may be a bit too subtle.
| nine_k wrote:
| On topic: does the open-source Coreboot fare any better here?
| (I hope it does; the article does not mention it.)
| est31 wrote:
| coreboot just initializes the hardware, the logo is something
| that the payload displays: https://www.coreboot.org/Payloads
|
| The most typically used payload is u-boot:
| https://docs.u-boot.org/en/latest/
|
| u-boot supports specifying splash screens via "splashfile",
| but it seems only bmp and maybe some raw image format are
| supported: https://github.com/u-boot/u-boot/blob/2f0282922b2c
| 458eea7f85...
|
| In other words, no support for png, which this exploit uses
| :). That doesn't mean that coreboot/u-boot aren't written in
| C though which is a language known for its vulnerabilities.
| a1o wrote:
| > which is a language known for its vulnerabilities
|
| C is not known for its vulnerabilities, it's known for
| being fast, portable, and low on abstractions. It's a
| perfect fine language to write this kind of code. There are
| techniques like fuzzing and using things like valgrind that
| can catch invalid input and memory issues quite quickly.
| pgeorgi wrote:
| coreboot has a rather fragile JPEG parser for splash screens
| but the saving grace is that barely anybody uses it because
| that's normally the payload's job (the jpeg + display thing
| was mostly added for a proof of concept "look how fast we can
| boot" demo in 2005)
|
| With payloads, some are more at risk than others. edk2 might
| run into issues here, grub2 has tons of features where stuff
| like this might hide in, other payloads (e.g. ChromeOS'
| depthcharge) are more limited in their functionality and
| therefore in their attack surface, too.
| chx wrote:
| C code? Nah, my friend, firmware is written in SPARK to achieve
| the highest possible quality. /s
|
| (and yes it should have been written in it, arduous it is, it's
| a "you had one job" situation)
| gpderetta wrote:
| Firmware _and_ BIOS vendors, world renown for the quality of
| their software.
| dingnuts wrote:
| genuine question: is this sarcasm? how dumb am i for not
| being able to tell?
| jacquesm wrote:
| Yes.
| sonicanatidae wrote:
| You're not dumb. You simply lack the specific body of
| knowledge and industry experience that provides the context
| for you to determine this.
|
| That's just life. :)
| jsight wrote:
| Of course their software is the best. Some of these vendors
| are subject to regulatory, contractual legal requirements.
|
| That always produces the best software, unlike the "move
| fast, break things" people in other domains.
| imoverclocked wrote:
| I've been in the move fast and break things domain.
| Unsurprisingly, things are often broken there too.
| jsight wrote:
| I've yet to run into place where they aren't. But run
| fast, fix fast often works better than constant debate
| and red tape.
| a_subsystem wrote:
| Currently working on a new federal report requiring us to
| send 7 fields to them yearly. They have provided a 1,670
| page document to 'help' us send them the data.
| WesolyKubeczek wrote:
| Since it's always turtles^Wsubcontractors all the way down, I
| wouldn't be surprised in the least if some of the actual
| mission critical stuff turned out to be written by some
| unpaid intern at an underpaid outsourcing shop somewhere in
| Elbonia. And if it would be in fact the most solid and
| reliable piece of the firmware.
| toyg wrote:
| _> Elbonia_
|
| Showing your age there, pal. And yes, the '90s were
| awesome.
| themaninthedark wrote:
| We need UEFI! With out it everything is ancient. And it needs
| to be updateable from the internet and the OS.
| forgetfreeman wrote:
| Not sure if sarcasm...
| loxias wrote:
| Yeah, and it should (somehow) involve javascript/wasm and Big
| YAML.
| baz00 wrote:
| As a former firmware developer I would like to point out that I
| lacked the competence and interest to have done a good enough
| job of it past getting paid at the end of the month.
| bcantrill wrote:
| Indeed -- and not coincidentally, this is why we don't have
| UEFI at all on the Oxide compute sled.[0]
|
| [0] https://www.osfc.io/2022/talks/i-have-come-to-bury-the-
| bios-...
| Voultapher wrote:
| Hey, big fan of your work. Keep up the great work.
| beeboobaa wrote:
| Yet again we're shown that secure boot and TPMs are security
| theatre designed for DRM and not to protect you, the user.
| nine_k wrote:
| A TPM is a pretty useful thing, but all it can do is to
| securely store secrets.
| eimrine wrote:
| To securely store some secrets from the user?
| Avamander wrote:
| From everyone, if needed.
| eimrine wrote:
| Everyone minus vendor and his jurisdiction, I guess.
| nine_k wrote:
| Yes. E.g. there are cases when it's much better to lose
| your disk encryption key and the entire disk's contents
| with it than to let a third party see it. So the disk
| encryption key may live in a TPM. This is supported by
| LUKS, for example.
| mschuster91 wrote:
| Still pointless when the key can be sniffed in cleartext
| by intercepting the communication between the TPM and the
| CPU [1]. You should _always_ combine it with something
| only known to the user (i.e. a passphrase).
|
| The only attack TPM-backed disk encryption prevents is
| someone imaging the disk.
|
| [1] https://blog.scrt.ch/2021/11/15/tpm-sniffing/
| chrismorgan wrote:
| > _The only attack TPM-backed disk encryption prevents is
| someone imaging the disk._
|
| The last section of the article you link says TPM 2.0 may
| fix the sniffing attack. It's also worth noting that
| "someone imaging the disk" was _really easy_ if you got
| even fairly brief access to the computer, whereas the
| other attacks that may still be viable involve invasive
| surgery and specialised knowledge of the hardware in
| question.
|
| (This is my understanding as a developer not
| _particularly_ informed about boot arrangements, upon
| reading some relevant material. I could be wrong or have
| missed some nuance.)
| hulitu wrote:
| > The last section of the article you link says TPM 2.0
| may fix the sniffing attack
|
| English is not my native language but, as far as i know,
| _may_ expresses uncertainity.
| dan000892 wrote:
| ...or booting from alternate media to retrieve data from
| the disk in situ (depending on which measurements are
| used to seal the key in the TPM).
|
| "Don't let perfect be the enemy of good."
| Vulnerabilities/limitations should be understood and you
| have every right to determine that TPM+PIN is the minimum
| control that addresses threats you've modeled and reduces
| risk to a tolerable level, but TPM-only encryption is not
| pointless. It reduces risk by increasing required attack
| complexity without impacting usability. That's enough for
| a lot of people.
| devbent wrote:
| > You should always combine it with something only known
| to the user (i.e. a passphrase).
|
| The fact this isn't mandatory blows me away. I remember
| when my work machine first got TPM full disk encryption,
| a passphrase was needed.
|
| A few years later? Meh. Who needs "real" security.
|
| Of course I get it is a convenience trade off, it almost
| always is.
| mschuster91 wrote:
| It's especially because Microsoft doesn't want to deal
| with people who manage to forget their unlock code or
| those who die without having a break-glass kit deposited
| at a bank locker, leaving their relatives in quite the
| mess.
|
| I get it, for everyday people TPM-only is enough, but
| anyone remotely security-minded (or anyone traveling to
| the US and thus subject to the whims of the CBP) is
| better served with a good passphrase.
| LoganDark wrote:
| Yes, exactly. The user is the enemy.
| MBCook wrote:
| Apple has it working just fine.
|
| Don't blame shoddy implementations by companies who are only
| checking checkboxes.
| stefan_ wrote:
| While Apple will spend billions on the latest techniques to
| ensure your iPhone can only run things Apple signed, there is
| meanwhile a real lack of enthusiasm around the basics like
| making the central messaging app not a native code shitshow
| invoking obscure (native of course) open source libraries
| they never update, you know, the basics. It's the latter that
| keeps getting their customers exploited.
| hug wrote:
| Why are you emphasising _native_ code? Is there something
| about native code being bad that I am missing?
| bigstrat2003 wrote:
| This is an absolutely terrible take. Just because the mechanism
| doesn't provide perfect security doesn't mean a) it provides
| none, or b) it isn't even trying to provide security.
| stefan_ wrote:
| "Secure boot", despite the name, really has very very little
| to do with security and everything with only running
| "sanctioned" code, even if that sanctioned code is an ancient
| browser engine or 300 MiB worth of .text.
| ajross wrote:
| Better an ancient browser engine and 300 MiB worth of .text
| than a trojaned userspace launched by someone with a USB
| stick.
|
| This is a bad take. Authenticated and validated secure boot
| is an important feature that keeps us all safe.
| stefan_ wrote:
| If someone has access to the hardware you have lost
| already. The other argument people make is that it
| prevents "persistence", as in the "authenticated and
| validated" code is actually a remote code execution
| engine, but while it does that, at least it can't be
| modified to be.. even worse? It's little consolation
| really.
| ajross wrote:
| > If someone has access to the hardware you have lost
| already.
|
| Tell that to my Chromebook that you can't crack. Or a
| Macbook. Or your phone. Or even a UEFI device absent the
| occasional vulnerability like this. There are
| vulnerabilities, but they're comparatively rare and they
| get patched.
|
| In fact this is simply wrong. Defense of systems against
| attackers with physical access is a mostly solved
| problem, and secure boot is the answer. It is not (and
| never will be) perfect, but it does work.
| stefan_ wrote:
| Who is cracking anything? The problem with physical
| access is that at the end of the day your security is
| only as good as the flat flex cable transporting your key
| presses.
|
| This is not some science fiction scenario; look at the
| "addin boards" they found in CryptoPhones (you know that
| thing was using secure boot!):
|
| https://www.cryptomuseum.com/crypto/gsmk/ip19/implant.htm
|
| Nobody cares to exploit or modify the software if at the
| end of the day what you are trying to protect is running
| across a PCB trace and they have physical access.
| k8svet wrote:
| Very interesting link, though I'm very disappointing it
| doesn't include speculation on when/where/how the bug was
| introduced to the phone. Also, I'm pretty surprised I
| hadn't come across the info that Wikileaks was bugged.
| Thanks for sharing.
| jacquesm wrote:
| Mad respect for whoever designed that, for a tailor made
| small series design that is an incredible piece of work.
| The component density alone is probably some kind of
| record. Note the Spartan 6.
| devbent wrote:
| That literally seems like it taps the microphone wire to
| record raw audio signals.
|
| Brilliant, but not a software or hardware issue.
| (Although actually having the device brick itself if it
| is opened up would have prevented the bug from being
| inserted).
|
| Likewise secure PIN pads are easily "defeated" by a
| camera.
|
| Plenty of TPM devices are encased in epoxy and designed
| to self destruct if tampered with. And lots of modern day
| devices (iPhones, game consoles) have stood up to years
| of attempts to exfiltrate their secrets.
|
| Work arounds are possible, but the industry has, for
| better or for worse, figured out how to make secure
| secret stores.
| hulitu wrote:
| > And lots of modern day devices (iPhones,
|
| NSO ? I mean, am I the only paranoic that thinks that
| Apple fixes its holes only _after_ other people make them
| public ?
| lwkl wrote:
| There are a lot of companies that are paid big bucks by
| nation states to find vulnerabilities and not make them
| public. NSO for example. So yes Apple only fixes the bugs
| people or companies find that make them public. But not
| for the reason you are implying.
| forgetfreeman wrote:
| I'm sorry but you've lost this argument the moment you
| advanced the claim that there are largely solved problems
| in the context of computer security.
| sonicanatidae wrote:
| +1 freeman. I work in and around this all day.
| Syonyk wrote:
| > _Tell that to my Chromebook that you can 't crack._
|
| Can I have it for a week or two, then send it back?
|
| Chromebooks are quite robust against remote attacks, and
| they're fairly robust against local physical attacks, but
| "Put an external interface on the NOR SPI flash and put
| whatever you want there" defeats just about everything
| they do with secure boot, because you can put your own
| code there instead. Or, on at least some devices, just
| remove the write protect screw and run some
| incantations[0].
|
| If you have physical access, very few systems are
| designed to be trustworthy in those cases. Even if you
| have a ROM root of trust somewhere, if it's on the board
| it can be desoldered and replaced with a different one
| (and I'm not aware of any hardware that does more than
| "write protect regions of the SPI flash - it can be done,
| but it's certainly not common).
|
| Even the TPM can be physically de-encapsulated and be
| manipulated/have data read out, if it's a discrete
| physical device.
|
| [0]: https://www.chromium.org/chromium-os/developer-
| information-f...
| ajross wrote:
| > Chromebooks are quite robust against remote attacks,
| and they're fairly robust against local physical attacks,
| but "Put an external interface on the NOR SPI flash and
| put whatever you want there" defeats just about
| everything they do with secure boot, because you can put
| your own code there instead
|
| This hasn't been true for a decade or more. Boot ROMs are
| validated by on-chip firmware in the modern world (not
| just on Chromebooks, everywhere). You can flash the chip
| with your JTAG gadget, sure, but if doesn't have a
| signature that works it won't do anything but brick your
| board.
|
| No, the obvious holes have long since been plugged. The
| design is secure. The implementation may have holes, but
| on the whole you can't break into an arbitrary box. You
| need to get lucky with a crack like the one in the linked
| article.
| amluto wrote:
| Secure Boot, under its default configuration, doesn't
| actually prevent running a trojaned userspace off a USB
| stick. It tries to block trojaned _kernels_ on a USB
| stick, and does every bit as bad a job of this as you
| would expect given the quality of the spec, the quality
| of the code, and the degree to which the problem is not
| very well defined.
| JohnFen wrote:
| > Authenticated and validated secure boot is an important
| feature that keeps us all safe.
|
| It also causes a great deal of trouble (at least for me),
| which is why disabling it is the first thing I do when I
| get a new machine.
| halJordan wrote:
| You're at the very least confusing threat models. The
| vendor is a source of trust. Not running unsanctioned code
| was never supposed to magically fix vulnerabilities. Acting
| offended when it didn't is just a bad look.
| r00fus wrote:
| A sole vendor who is not trustworthy is not a source of
| trust. Microsoft has done little to earn trust other than
| to make money from users.
| ajross wrote:
| This isn't related to secure boot or TPM/hardware-secrets-
| management. It's just an vulnerability[1] in some
| configurable[2] software running with privilege. This is
| downstream of the TPM keys for sure, and running validated
| blobs from the perspective of secure boot.
|
| You could have this bug with or without that stuff, and it
| would be bad either way.
|
| Or maybe you're trying to say that secure boot is an impossible
| problem and we shouldn't try? No, it clearly works. Boot cracks
| on UEFI devices are real, but comparatively rare.
|
| [1] An image format parser bug
|
| [2] To display that image at boot
| amluto wrote:
| > This is downstream of the TPM keys for sure
|
| Not really. The UEFI firmware is supposed to extend PCRs in
| the TPM based on what it does, but it looks like these
| vulnerabilities allow taking over the firmware before it does
| this and thus allows spoofing of what goes in those PCRs.
| Which breaks TPM security.
| dist-epoch wrote:
| Even bigger security flaws were found in OpenSSL, Firefox or
| the Linux kernel.
|
| Are they also security theater?
| halJordan wrote:
| Of course they are. Openssl didnt prevent that malware from
| modifying a ufi driver so of course it's worthless.
| jeroenhd wrote:
| No, I think this shows that adding customisability features to
| please a small minority of users into low level components can
| be a huge security risk. Secure boot and TPMs aren't the
| problem here, the inclusion of user-configurable images and
| insecure image decoders is.
| sounds wrote:
| Secure boot and TPM that only come with PCIe card drivers
| signed by the Microsoft CA are definitely the problem here.
|
| If it weren't closed and controlled by one large
| corporation's interests, there wouldn't be a monoculture,
| which would make this less severe of a vulnerability.
| DaiPlusPlus wrote:
| > No, I think this shows that adding customisability features
| to please a small minority of users into low level components
| can be a huge security risk
|
| Customization of the POST boot logo image should be as simple
| as burning an image to a simple flash ROM which remains
| untrusted and data-only (no-execute) - the fact that
| performing these ostensibly harmless customizations will
| introduce a security issue just leads me to believe an
| intelligence agency is involved somehow...
|
| I mean, it makes sense: one can probably convince the leaders
| of Hamas or Cuba that it's worthwhile to let the 14yo great
| nephew twice-removed of an inner party cadre member to
| replace their laptop's _capitalistic_ imagery from ASUS
| /Acer/Razer/Dell with some JPEG with far more _revolutionary
| appeal_ - they 'd never suspect a thing...
| Lammy wrote:
| Even worse: they're security non-theater designed to protect
| "the computing environment" _from_ you, the user.
| roywiggins wrote:
| Putting an image parser in the first stage of boot seems like a
| mistake in the first place tbh. Surely you could skip that and
| just bake the decoded image into the firmware? Or is this all so
| vendors can rebrand their BIOS without having to rebuild and sign
| it?
| reginaldo wrote:
| You nailed it. This is so vendors can rebrand without having to
| rebuild and re-sign.
| Arnavion wrote:
| IIUC There are two vectors:
|
| 1. Logos in EFI binaries (OS, bootloader, shell, etc), not the
| UEFI firmware logo itself. For these, "bake it into the
| firmware" is not relevant because these are just files that
| anything, such as malware, can drop into the ESP.
|
| 2. The UEFI firmware logo itself. This would only be updated by
| firmware updates, which ought to be signed, but apparently
| these vendors put the logo in non-signed sections, so malware
| could edit a pending update to use a malicious image.
| tadfisher wrote:
| Lenovo ships the standard Phoenix shell app named
| ShellFlash.efi (which calls itself ShellFlash64). One of its
| CLI flags is to flash the UEFI logo. The Lenovo BIOS package
| includes instructions to update the logo by dropping the
| image file in the ESP where their updater (BootX64.efi) can
| find it.
|
| So flashing unsigned logo images is supported and intended
| behavior here.
| jeroenhd wrote:
| From what I can tell by the demo video, the Windows process
| seems to be injecting the bitmap before calling a reboot
| without calling into the flash utility.
|
| I wish I could put up a nice customised image without
| having to mess with firmware files. It's kind of stupid to
| include a logo feature but then to remove the image file
| every time you install an UEFI firmware update.
| p_l wrote:
| UEFI update protocols have a variant where you store the
| update Capsule in memory, mark it so that it's not
| overwritten on reboot and picked up by update handler
| during boot.
|
| The same protocols are afaik used by the bootable
| updaters (there are IIRC three ways to pass the update
| capsule to flasher that is actually part of the firmware)
| halJordan wrote:
| The point of uefi was to unlock the future bios was preventing.
| It's crazy how quickly the mob forgets and then turns against
| what it used to love.
| forward1 wrote:
| The risk is "image parsers in UEFIs ... are riddled with roughly
| a dozen critical vulnerabilities" but what is the attack vector?
| Has a dropper been identified? Or is this an academic finding
| only?
| roywiggins wrote:
| > There's no indication that LogoFAIL vulnerabilities have been
| actively exploited in the wild, but there's also little way one
| would know, since infections are so hard to spot using
| traditional tools and methods.
| nine_k wrote:
| Their idea of an attack vector: local exploit or phishing ->
| privilege escalation -> accessing the UEFI partition.
|
| Say, an installer of a pirated game might pull this off, and
| turn your machine into a permanent botnet node, incurable by
| standard means, and maybe undetectable. But this is a low-value
| target; a usually dormant, stealthy fileless malware on a
| laptop that belongs to a CEO or a high-ranking government
| official may be much more insidious and impactful.
| johnea wrote:
| UEFI is just another M$ abomination 8-(
|
| In this specific vulnerability, I wonder how possible it is to
| modify that boot logo remotely?
|
| Wouldn't exploiting this vuln require local access?
|
| As in all things, open firmware is the way to go:
|
| https://www.linuxboot.org/
|
| https://libreboot.org/
|
| https://www.coreboot.org/users.html
| forward1 wrote:
| Do Libreboot supported hardware devices, which appear quite
| old, still receive CPU patches? If not, it is probably time to
| stop using it. Coreboot may give you a fighting chance however.
| justaj wrote:
| IIRC LB supports microcode updates, but I don't think older
| CPUs will receive new microcode updates from CPU vendors.
|
| Then again, newer CPUs have a host of other problems, like
| only supporting platforms where rolling your own boot
| firmware / UEFI is next to impossible.
|
| Personally I think the CPU has a much lower attack surface
| than something like UEFI (microcode updates are also pretty
| tiny), so I would rather have an outdated CPU than an
| outdated / vulnerable UEFI implementation.
| forward1 wrote:
| Disagree entirely. With an outdated CPU, you could be owned
| just by running Javascript on the wrong site. Not so with a
| vulnerable UEFI/BIOS, that requires additional privesc as
| is seen here.
| WesolyKubeczek wrote:
| Okay,
|
| how do I even change the boot logo in BGRT so it persists across
| boots? From userspace, no less? And how do I turn them off? On
| your generic dell/lenovo boxes I doubt it's even possible.
| nine_k wrote:
| Do you even run installers from not entirely trusted third
| parties, or curl | sudo bash type of thing? That could sneak
| in.
| WesolyKubeczek wrote:
| Yes, but how do I do it if I want to do it for my own
| amusement?
| p_l wrote:
| Lenovo uses Phoenix provided tool that will prepare
| compatible graphic image into update capsule and pass it to
| flasher program (embedded in the firmware)
| forward1 wrote:
| Thanks. My take is on this is root access -> stealthy bootkit.
| Further demonstrates "secure" boot and similar DRM is theater
| only.
| AshamedCaptain wrote:
| On the defense of the secure boot illusionists, though, I'm
| going to imagine that _anyone_ who was actually concerned about
| secure boot working as intended would have disabled the running
| kernel from accessing UEFI variables and the UEFI system
| partition.
| k8svet wrote:
| AFAIK, while supporting XBOOTLDR, the systemd project still
| encourages /boot to be on the ESP if possible.
|
| Personally, I don't understand why they advocate this. Beyond
| separation of concerns and situations like this, it also
| seems more realistic to advocate for XBOOTLDR style
| deployments in the face of dual boot systems and Windows
| creating an anemic ESP nowadays.
| gunapologist99 wrote:
| > Personally, I don't understand why they advocate this.
|
| It seems easier to explain if you don't mind choosing from
| a nice range of conspiracy theories about what systemd is
| and why it has spread like a virus.
| amluto wrote:
| > disabled the running kernel from accessing UEFI variables
| and the UEFI system partition.
|
| How exactly do you propose doing that? I suppose you could
| see if OPAL can block writes to the ESP, but that does
| nothing about efi vars.
| bawolff wrote:
| So in secureboot, do images used not to be signed? Otherwise how
| does this work?
|
| That seems like an odd flaw
| nine_k wrote:
| The images are in the unsigned section :( It's more convenient
| to OEMs and corporate customers this way :(
| eimrine wrote:
| Will this help in de-obfuscating the notorious Intel ME and/or
| its analogs?
| ok123456 wrote:
| ME was leaked years ago.
| doublerabbit wrote:
| Although, "file to hard-drive" isn't possible if you use
| BitLocker, LVM or ZFS Encryption.
|
| More a reason too.
| pavon wrote:
| Those don't encrypt the EFI system partition, which is where
| the image in question is stored.
| jmclnx wrote:
| I still use BIOS and I hopefully never be forced to use UEFI or
| Secure Boot. Again RMS and Theo both came out against UEFI
| (IIRC). But $ mean more in security.
|
| > that have lurked for years, if not decades, in Unified
| Extensible Firmware Interfaces responsible for booting modern
| devices that run Windows or Linux
|
| What does this mean, "decades" ?? I kind of doubt it. I guess we
| cannot have a article without sensationalism.
| yjftsjthsd-h wrote:
| If BIOS is immune to this, it's only by coincidence; there's no
| reason to think older firmware that allows the user to set the
| boot logo isn't equally riddled with vulnerabilities.
| jmclnx wrote:
| Last I heard, BIOS firmware is forced to be 64k (or 128k),
| but that limit could have changed over the years. Not much of
| a logo would fit with that limit.
|
| edit: just checked, the BIOS in my newest laptop ~10 years
| old is 128k. But the ROM size is 12M which is interesting. I
| can enable UEFI so I can only guess the remaining space is
| used for that.
| yjftsjthsd-h wrote:
| I mean, I don't know how it's stored, but it does still
| have a boot logo. I guess _if_ it only supports really tiny
| logo files for whatever reason that reduces the amount of
| code an attacker can give it, but that doesn 't feel like a
| very good defense. Edit: Oh, or if the older firmwares only
| supported a logo that was hardcoded into the image and that
| can't be updated separately, that might help. Still
| coincidental, though; you certainly _could_ have a user-
| controlled logo with BIOS, and as the article notes, there
| are UEFI implementations that also hardcode the logo.
| p_l wrote:
| In reality you have UEFI and the 128k is 16bit shim code of
| the Compatibility Support Module that emulates BIOS
| interfaces.
|
| UEFI Class 1 devices (which had hardcoded CSM and didn't
| allow access to UEFI APIs from bootloader or OS) started
| shipping as early as 2005 - because it made it much simpler
| to build firmware especially when you're supposed to
| integrate complex vendor specific code (for example from
| Intel).
|
| Even before that, it was not uncommon for BIOS to actually
| be much bigger than 128k. Logos were also common as part of
| BIOS. Hell, 1990s had a bunch of BIOSes with GUIs with
| mouse support. Some even tried to emulate look&feel of
| Windows.
|
| At least UEFI provides a graphics toolkit that supports
| rendering to both GUI and serial port, so you don't have to
| deal with BIOSes that can't be connected to over serial
| because they need VGA raster output...
| iwontberude wrote:
| PCBIOS is just a compatibility mode for UEFI chipsets now, so
| there is no avoiding it -- sorry :(
| dist-epoch wrote:
| All computers newer than 10 years are based on UEFI.
|
| Which exposes a BIOS emulation layer: CSM (Compatibility
| Support Module)
| Nullabillity wrote:
| If "running OS can cause the computer to load unsigned code" is
| something you care about, BIOS is already "vulnerable", by
| virtue of not even trying to prevent it.
| instagib wrote:
| there are 3 paths.
|
| 1. placing logo into ESP (EFI System Partition) via admin
| privileges
|
| 2. Bios update tool
|
| 3. When there is no expected way to customize the logo, it is
| still possible via physical attack vector: just with an SPI flash
| programmer if a logo is not covered with any hardware-based
| Verified Boot technology like Intel Boot Guard or AMD Hardware-
| Validated Boot
|
| "As we can see in the following table, we detected parsers
| vulnerable to LogoFAIL in hundreds of devices sold by Lenovo,
| Supermicro, MSI, HP, Acer, Dell, Fujitsu, Samsung and Intel. "
|
| https://binarly.io/posts/finding_logofail_the_dangers_of_ima...
| neilv wrote:
| > _Image parsers in UEFIs from all three major IBVs are riddled
| with roughly a dozen critical vulnerabilities that have gone
| unnoticed until now._
|
| If your code has a dozen vulnerabilities, it has more than that.
|
| Also, every time I see a 2D image library, I assume it almost
| certainly has vulnerabilities. There's something magical about
| the task of coding 2D image libraries, such that it really calls
| out how bad we are at writing correct code (especially in C).
| hulitu wrote:
| > (especially in C).
|
| I thought iMessage was written in ObjectiveC. /s
| Guvante wrote:
| As easy as it seems to be to just include an image decoder it
| feels like "must be a specific size bmp file" is a perfectly
| acceptable solution here.
| DaiPlusPlus wrote:
| ...but what if the "must be a specific sized BMP file" rule
| is because if you were to flash the eprom with, say, a PNG
| file it meant you suddenly got root over Intel's Management
| Engine in your CPU?
| yjftsjthsd-h wrote:
| This is one of the reasons I'm a big fan of wuffs[0] - it
| _specifically_ targets dealing with formats like pictures,
| safely, and the result drops in to a C codebase to make the
| compat /migration story easy.
|
| [0] https://github.com/google/wuffs
| pgeorgi wrote:
| See also https://review.coreboot.org/c/coreboot/+/78271 :-)
| yjftsjthsd-h wrote:
| Oh, very nice:) Great to see that!
| flashback2199 wrote:
| > 2D image library
|
| Maybe I'm ignorant but what's a 1D image ?
| Wingy wrote:
| A line of pixels.
| flashback2199 wrote:
| Ah ok. It sounds like it's important to distinguish the two
| by saying 2D image, but I'm sure the reason is too advanced
| for me.
| yjftsjthsd-h wrote:
| More likely to be distinguishing 2D from _3D_ graphics,
| and just saying "image" can be ambiguous when firmware
| images are in play.
| DaiPlusPlus wrote:
| So, are video-files of 2D images technically 3D then?
|
| and time-based volumetric recording of 3D video-games are
| 4D?
| picture wrote:
| Time doesn't necessarily have to be another dimension.
| They're just what they are but organized in time.
| starttoaster wrote:
| I'd highly recommend reading Flatland. Not only because you
| had to ask this, but because it's a fun (and short) read.
| alexb_ wrote:
| Scan lines?
| LoganDark wrote:
| What's wrong with simply not running malicious software? Is it
| supply chain attacks?
| fortran77 wrote:
| This should say "just about every UEFI device". The problem has
| little to do with any particular OS.
| reginaldo wrote:
| I wonder if anyone tried this in Android, which also has a logo
| partition. Maybe not the flagship phones, but if I were to guess,
| I'd guess the TV sticks and other Android streaming devices might
| have similar issues.
| peppermint_gum wrote:
| If a local vulnerability that requires administrative privileges
| to exploit is "high impact", I wonder how they would classify
| remote code execution. Super duper high impact?
|
| This of course needs to be patched, but it's way overblown. This
| vulnerability alone provides no attack vector, you need other
| vulnerabilities to be able to replace the logo.
| gunapologist99 wrote:
| But an RCE goes away as soon as you re-OS. Once your UEFI is
| pwned, you might as well pitch the box in the rubbish bin.
| 1970-01-01 wrote:
| Nobody enjoys dealing with UEFI. Its a very ugly mess of a
| standard that is an order of magnitude more complicated compared
| to BIOS.
| NelsonMinar wrote:
| SecureBoot and UEFI is a regular pain in my ass. Just yesterday I
| couldn't run memtest86+ on a new computer because of it. I'm
| installing a bunch of Linux VMs these days and both on the real
| hardware and in the VM images UEFI and SecureBoot is a constant
| source of stress.
|
| And it doesn't even work? Because the firmware authors used
| crappy code to display marketing images?
|
| I want my tens of hours back.
| tryauuum wrote:
| at least you can run VMs with traditional boot
| jeroenhd wrote:
| Disabling secure boot takes like five seconds, I don't see what
| the big deal is.
| Lammy wrote:
| I don't feel comfortable depending on a vendor to expose that
| switch. Once all the Secure Boot infrastructure is built out
| all it will take is one more decision for them to stop giving
| me an option.
| sounds wrote:
| Start installing coreboot then?
| Lammy wrote:
| I do use coreboot on my 51nb faux-ThinkPad X210 thanks to
| @mjg59 :)
| ok123456 wrote:
| Some cheap laptops have forgotten to expose that switch.
| fragmede wrote:
| At which point all hardware that currently exists which you
| already own will get remotely updated out from under you so
| you can't boot your own kernel?
|
| I get that being allowed to run the code you want on
| hardware you own is paramount, but let's not live in fear
| of hypotheticals. There are already secured platforms like
| the Xbox/PS5/iphone where we don't have that option and the
| world hasn't ended.
| zlg_codes wrote:
| How do you expect the ecosystem to look in 20 years?
| You're simply not thinking far enough ahead.
|
| "it's only a few right now don't worry about it" More
| happen. "okay maybe I see where you're coming from but
| it's still avoidable!" It continues. "I still have
| options I don't know what your problem is." Eventually,
| no choice. "How did we get here!?!?!"
|
| We need protective regulations that ensure that general
| computing is accessible to every citizen. Giants of
| industry are not entitled to control devices that they
| sell after they are sold.
| NelsonMinar wrote:
| If your BIOS allows it. Some don't, or if you disable Secure
| Boot you lose other motherboard features. My home server is
| an ASUS motherboard that loses Intel integrated graphics
| without UEFI, which makes installing an OS awkward. https://w
| ww.reddit.com/r/ASUS/comments/s68b25/psa_enabling_l...
|
| Also like a sucker I thought secure boot was doing something
| to help secure the boot of my computer and was worth the
| bother.
| JoshTriplett wrote:
| Disabling Secure Boot is not the same as enabling CSM (non-
| UEFI boot). You can disable Secure Boot while still booting
| via UEFI without CSM, and that shouldn't affect your
| graphics at all.
| loxias wrote:
| Even with it disabled sometimes you're still locked into this
| UEFI mess that I certainly didn't order.
|
| I love my thinkpad p1 g3 more than most laptops but I miss
| having a simple BIOS. Stupid thing can't boot off normal USB
| keys like I've been making for decades.
| upofadown wrote:
| How about we just have a physical switch that you have to
| activate to update the firmware? I don't care about the rest of
| the software in the boot chain, an attacker can just trojan any
| binary that runs as root to get the same effect. As a user I
| don't care about the distinction between boot and the rest of the
| time.
| TacticalCoder wrote:
| > How about we just have a physical switch that you have to
| activate to update the firmware?
|
| A very long time ago motherboards _were_ like that. You couldn
| 't flash the firmware without first physically moving a jumper
| on the motherboard (btw what you're asking for typically would
| be done with a jumper, not a switch, AFAIK).
|
| I remember a very heated argument with a friend of mine when I
| got my first mobo that didn't require a jumper to be physically
| modified to be able to flash the firmware. I told him it was
| heresy and that, invariably, exploits would come.
|
| Note that these first mobo that could see their firmware
| flashed without requiring changing the position of a jumper had
| literally not confirmation asked of anything. You'd just flash
| the firmware by running an exe.
| jml7c5 wrote:
| Chromebooks did this for a while; they had a write-protect
| screw on the motherboard that had to be removed to enter
| developer mode and/or flash custom firmware. Once you were
| done, you could reinsert the screw to lock it back down again.
| userbinator wrote:
| Bit of a nothingburger IMHO, but as usual the corporate
| bootlicker types want to scare the hell out of everyone.
|
| Flashing the BIOS from within the OS never seemed like a good
| idea to me[1], but if you can do that then you can replace it
| with whatever you want. I also recall replacing the Energy Star
| logo with something more amusing was at one point a semi-common
| BIOS mod.
|
| [1] I remember the story of a certain company that included
| silent automatic background BIOS updates in the preinstalled
| bloatware of its laptops, and the subsequent large number of "I
| didn't do anything but reboot and now it won't even turn on
| anymore" reports.
| gunapologist99 wrote:
| Not exactly a nothingburger; this makes your machine _once and
| always pwned_.
| iforgotpassword wrote:
| It would be fun to collect all the exploits of EFI and secure
| boot and create some sort of super-bootloader-shim thingy that
| tries to work on as much hardware as possible where secure boot
| is enabled.
| butz wrote:
| Is this the end of the "secure passkeys"?
| slicktux wrote:
| Epic!
| to11mtm wrote:
| This does make me ask questions; namely, why the hell would
| anyone risk allowing compression more complex than RLE [0] in a
| firmware picture format? It's almost asking for trouble.
|
| [0] - Maybe there's something else out there that works better
| with similar ease of doing safely low level, would love to know
| other options!
| xnx wrote:
| John Carmack suggests using something even more basic than RLE:
| "Media file parsing has been behind so many security issues. In
| many cases today, using completely raw data is very practical.
| No DCT. No ADPCM. No RLE. Just raw pixels/samples. There should
| be a widely agreed on header for modern raw data that is just a
| non-extendable struct."
|
| https://twitter.com/ID_AA_Carmack/status/1732519369362596262
| mlindner wrote:
| [delayed]
___________________________________________________________________
(page generated 2023-12-06 23:00 UTC)