How does an image serve malware to UEFI?

[Paddy Landau]

I read today that a serious UEFI flaw allows an image (e.g. of the OEM's logo), intended for display at boot, to serve malware to the UEFI system, thereby bypassing its security. (This isn't specific to a single operating system.)

I'm nonplussed. I don't understand how an image can do this. After all, an image just a piece of data "copied" to a screen, isn't it? You don't run an image like a program, do you?

Can you explain in simple terms how an image can do this, please?

[grahammechanical]

Some years ago I read about the possibility of hiding a message in among the data making up a digital image. Only those in on the secret would know how to separate the message from the image. Everyone else would not even know that a message was being communicated. All they would see is the image. It is called steganography.

If messages can be hidden this way why not computer code?

https://betterprogramming.pub/hide-d...e-507f571aab89

https://en.wikipedia.org/wiki/Steganography

It might be true that using an image this way is possible but the infected image still needs to be installed on the computer as the vendor's splash image. So, unless the original vendor's splash image has been infected and before it is used as a splash image and so compromising every machine with that particular splash image - and why would someone do that - I am not too troubled by this vulnerability. Or, should we say "possibility." Who was it that said: "All things are possible, but not all things are probable?"

Regards

[1fallen]

It might be true that using an image this way is possible but the infected image still needs to be installed on the computer as the vendor's splash image. So, unless the original vendor's splash image has been infected and before it is used as a splash image and so compromising every machine with that particular splash image - and why would someone do that - I am not too troubled by this vulnerability. Or, should we say "possibility." Who was it that said: "All things are possible, but not all things are probable?"

Regards

+1 Good Reply,
Because the UEFI is the first thing to run when a computer is turned on, it influences the OS, security apps, and all other software that follows. These traits make the UEFI the perfect place to launch malware. When successful, UEFI bootkits disable OS security mechanisms and ensure that a computer remains infected with stealthy malware that runs at the kernel mode or user mode, even after the operating system is reinstalled or a hard drive is replaced.

Now don't get all pariniod over that statement, there are a few formidable hurdles standing in their way. One is the requirement that they first hack the device and gain administrator system rights, either by exploiting one or more vulnerabilities in the OS or apps or by tricking a user into installing trojanized software. Only after this high bar is cleared can the threat actor attempt an installation of the bootkit.

Now I'm all ears on Secure Boot, and much more in favor these days, because industry-wide standard that uses cryptographic signatures to ensure that each piece of software used during startup is trusted by a computer's manufacturer. Secure Boot is designed to create a chain of trust that will prevent attackers from replacing the intended bootup firmware with malicious firmware. If a single firmware link in that chain isn’t recognized, Secure Boot will prevent the device from starting.
I knew there would be a day for me to really get behind Secure Boot. (That Day is Now)

[Paddy Landau]

Thank you for the replies.

I'm aware of stenography, and I understand that you could hide computer code in an image.

But, that computer code has to be executed. The purpose of an image is to display it on the computer screen (at least in the context of the UEFI boot process). Its purpose isn't to look for computer code and execute it.

So, my question is, how does that computer code inside the image get executed? The UEFI boot process displays the image; it doesn't execute the image.

That's what I'm getting all confused about!

[DuckHook]

Thank you for the replies.

I'm aware of stenography, and I understand that you could hide computer code in an image.

But, that computer code has to be executed. The purpose of an image is to display it on the computer screen (at least in the context of the UEFI boot process). It's purpose isn't to look for computer code and execute it.

So, my question is, how does that computer code inside the image get executed? The UEFI boot process displays the image; it doesn't execute the image.

That's what I'm getting all confused about!

Late to the party, but here are my two bits.

All code is just ones and zeros. When talking about computing, we often get confused by metaphors that really only anthropomorphize what is really happening. Though we may think that something is just being "displayed" (that is, "shown to us"), this is not what is actually happening at the machine level. In order to display something, the system needs to process that file (ones and zeros) through a parser that the developer assumes will only act in certain ways. However, if that parser is bugged, it will process that file in unexpected ways. If bad guys figure out what those bugs are, they can exploit them to process a file maliciously: say, by injecting instructions into system memory that the file is not "supposed" to access.

The problem here is that the system is at such a primitive state in its boot process that the usual mitigation measures have not been loaded yet. No apparmor, no memory protection, no nothin'.

And though I don't want to be alarmist, I think there's a real danger here. Supply chain attacks are well documented. They are ultra sneaky and hard to deal with. Moreover, there are still a lot of OEMs that are small and stretched thin or who don't take security seriously. Not all OEMs are Dells or HPs (though I'm not sure that having a big brand name provides much more in the way of security these days). Lastly, this attack vector can presumably also be exploited without displaying any logo at all if it just runs a "blank" logo that does nothing other than inject malicious code. And since the problem is in the firmware, this exposure could be resident in any of the small parts suppliers who make components for everything from smartphones to cars. It's no longer just what we used to call "computers" that we need to be worried about.

[Paddy Landau]

Thank you, DuckHook. So, it's a bit like a SQL injection? The parser is making assumptions that it shouldn't make.

I guess that makes sense. To understand it fully, I'd have to look at the parser's code and understand it, something that I'm not able to do.

But what you say does help me to understand, thank you.

[DuckHook]

…So, it's a bit like a SQL injection? The parser is making assumptions that it shouldn't make.

We're getting into areas that are way beyond my pay grade, but my understanding is that it's a bit more primitive than that:

SQL injections exploit a poorly designed high level function that exists to make browsers powerful. The parser issue is the opposite: at that stage, the BIOS designer wants to make the code as absolutely lean and mean as possible. After all, no libraries are loaded yet, so any functionality has to be self contained. In doing so, a lot of sanity checks are not done and security safeguards are nonexistent, which allows the "image" to barge into places that it has no business being in. But there's nothing to stop it if it does.

The real solution is take such parsers out of the system altogether. This is another instance of developers being pressured into adding pretty bells and whistles at the expense of functionality, security and good design. The boot process should be kept lean and mean—I agree with the parser devs on that score—but this should be applied so rigorously that the ability to display logos should not exist at all.