WebPWN'd - Actively used CVSS 10/10 rated Exploit performs Remote Code Execution on pretty much anything that handles WebP Images

[rcmaehl]

Summary

Don't use anything that can display WebP right now. Apple Google, and Mozilla have released updates though.

 

Quotes

Quote

Google has assigned a new CVE identifier for a critical security flaw in the libwebp image library for rendering images in the WebP format that has come under active exploitation. The development comes after Apple, Google, and Mozilla released fixes to contain a bug... that could cause arbitrary code execution when processing a specially crafted image. Both flaws are suspected to address the same underlying problem in the library. The decision to "wrongly scope" CVE-2023-4863 as a vulnerability in Google Chrome belied the fact that it also virtually affects every other application that relies on the libwebp library to process WebP images, indicating it had a broader impact than previously thought. An analysis from Rezillion... revealed a laundry list of widely used applications, code libraries, frameworks, and operating systems that are vulnerable to CVE-2023-4863. "Consequently, a multitude of software, applications, and packages have adopted this library, or even adopted packages that libwebp is their dependency." "The sheer prevalence of libwebp extends the attack surface significantly, raising serious concerns for both users and organizations."

 

My thoughts

Dear God. I guess I'm switching to w3m and IRC for the foreseeable future until the internet patches itself against malicious images running code on my devices. 

 

Sources

CVE report

Helpnet Security

The Hacker News (quote source)

Bleeping Computer

[Taf the Ghost]

And here I have been complaining about WebP handling for a while. 

 

But, yeah, that's really bad.  Update Browser time!

[Kisai]

So does that mean that everything that can play VP9 is vulnerable? Owch.

 

Too bad Safari for Windows hasn't been updated forever either. 

 

It can't really be understated enough that Chrome has been hiding the ability to turn off features that could prevent CVE's or malware from running.

 

I want the following abilities to return, either on a per-domain basis or browser-wide basis:

- Disable Javascript on this domain

- Disable WebASM on this domain

- Disable all video playback from this domain

- Disable all video using [h264|h265|VP9] [entirely|software codec|hardware codec]

- Disable WebGL on this domain

- Disable WebAudio API on this domain

- Disable WebSockets on this domain

- Disable Webcamera | Microphone | USB independently (ie, blacklist all but these devices from being visible)

 

 

And the logical reason why Chrome has been hiding these, is because it would allow end users to disable ads.  

[williamcll]

Big L for Webp. The only image format that matters is png

[hishnash]

Im always shocked by the idea that somehow these formats were designed in such a way that this would ever be possible.   Not just webP but almost every single major image and video format we use today has at some point had decoders writen for it that are someone subject to remote code execution.  

Don't our modern systems all have proper MMUs that are design to isolate executable code, I am not falmair enough with the internals of these formats but for this to be such a common thing does decoding these require you to run some form of JIT?  a plain old buffer overflow ect on a modern system with signed pointers and proper isolated executable memory regions should not result in a code injection. .. and yet here we are. 

[leadeater]

18 minutes ago, hishnash said:

Im always shocked by the idea that somehow these formats were designed in such a way that this would ever be possible.   Not just webP but almost every single major image and video format we use today has at some point had decoders writen for it that are someone subject to remote code execution.  

Don't our modern systems all have proper MMUs that are design to isolate executable code, I am not falmair enough with the internals of these formats but for this to be such a common thing does decoding these require you to run some form of JIT?  a plain old buffer overflow ect on a modern system with signed pointers and proper isolated executable memory regions should not result in a code injection. .. and yet here we are. 

Have a read of this: https://blog.isosceles.com/the-webp-0day/

 

Quote

The problem, we now know, is that this format is incredibly complex and fragile, and the preconditions to trigger this issue are immense. Out of billions of possibilities, we have to construct a sequence of 4 valid Huffman tables that are maximally sized for two different alphabet sizes (280 and 256) before constructing a very specific type of invalid Huffman table for a third alphabet size (40). If a single bit is wrong at any stage, the image decoder throws an error and nothing bad happens.

 

Like many vulnerabilities they aren't so simple and protections that are in place that are supposed to work don't always etc. Look at Side-Channel attacks, those worked with complete sandboxing and in cases even some forms of memory  and VM encryption etc.

[LAwLz]

8 hours ago, Taf the Ghost said:

And here I have been complaining about WebP handling for a while. 

 

But, yeah, that's really bad.  Update Browser time!

On this forum, or elsewhere?

Because I looked through your posts on here and you have never even mentioned WebP before.

Also, I find that most complaints about WebP can be attributed to the software those people use, not the format itself. Like "I downloaded a WebP image and the program I tried to open it with didn't support it, so the format is bad!" which I think is a ridiculous complaint.

 

 

6 hours ago, Kisai said:

So does that mean that everything that can play VP9 is vulnerable? Owch.

Does not seem like it.

The article specifically says the vulnerability is in libwebp. VP9 decoding is usually handled by libvpx.

 

 

2 hours ago, williamcll said:

Big L for Webp. The only image format that matters is png

I hope you're joking... PNG is great for some things, but awful for other things.

You need to use different image formats for different things.

[Taf the Ghost]

6 minutes ago, LAwLz said:

On this forum, or elsewhere?

Because I looked through your posts on here and you have never even mentioned WebP before.

Also, I find that most complaints about WebP can be attributed to the software those people use, not the format itself. Like "I downloaded a WebP image and the program I tried to open it with didn't support it, so the format is bad!" which I think is a ridiculous complaint.

 

 

Mostly a Reddit issue, but a lot of websites with WebP open them in this hybrid window when you want to zoom in on a bigger picture. Then you can't use normal zoom (as it zooms the UI). I've meant to find some add-on in browser to handle it, but I only remember it whenever I see a schedule post and want to zoom in.

 

No reason to bring it up around here, it's a processing annoyance I just need to bother to go fix.

[Dracarris]

26 minutes ago, leadeater said:

Have a read of this: https://blog.isosceles.com/the-webp-0day/

This is certainly a very interesting read, but after skimming through the technical analysis, I still don't get how the mechanisms @hishnash mentioned can be bypassed. No matter how you do it, once a process reads/writes past its allocated buffer sizes, the OS with support of the MMU - a hardware thing - should simply block these accesses from happening? Isn't that why we have OS and virtual memory addresses in the first place?

 

Also, Android users beware, if this is correct any image you receive on your favorite messaging app could be really bad news:

Quote

The bad news is that Android is still likely affected. Similar to Apple's ImageIO, Android has a facility called the BitmapFactory that handles image decoding, and of course libwebp is supported. As of today, Android hasn't released a security bulletin that includes a fix for CVE-2023-4863 -- although the fix has been merged into AOSP. To put this in context: if this bug does affect Android, then it could potentially be turned into a remote exploit for apps like Signal and WhatsApp. I'd expect it to be fixed in the October bulletin.

 

[leadeater]

2 hours ago, Dracarris said:

No matter how you do it, once a process reads/writes past its allocated buffer sizes, the OS with support of the MMU - a hardware thing - should simply block these accesses from happening? Isn't that why we have OS and virtual memory addresses in the first place?

Never assume something like that is actually protecting you, stuff like that should in theory but that is the whole point of exploits like these. They are causing situations that get around them. This is not "just a buffer overflow". If it were then you wouldn't have needed to find 4 out of billions, any overflow would work which it doesn't.

 

Quote

but the prize is an exploitable heap overflow that works on multiple browsers, operating systems, and applications. It's likely that CVE-2023-4863 is the same vulnerability used in the BLASTPASS attacks.

 

Quote

A heap overflow, heap overrun, or heap smashing is a type of buffer overflow that occurs in the heap data area. Heap overflows are exploitable in a different manner to that of stack-based overflows. Memory on the heap is dynamically allocated at runtime and typically contains program data. Exploitation is performed by corrupting this data in specific ways to cause the application to overwrite internal structures such as linked list pointers. The canonical heap overflow technique overwrites dynamic memory allocation linkage (such as malloc metadata) and uses the resulting pointer exchange to overwrite a program function pointer.

 

Quote

An accidental overflow may result in data corruption or unexpected behavior by any process that accesses the affected memory area. On operating systems without memory protection, this could be any process on the system.

 

For example, a Microsoft JPEG GDI+ buffer overflow vulnerability could allow remote execution of code on the affected machine.[1]

 

iOS jailbreaking often uses heap overflows to gain arbitrary code execution.

 

Quote

As with buffer overflows there are primarily three ways to protect against heap overflows. Several modern operating systems such as Windows and Linux provide some implementation of all three.

 

• Prevent execution of the payload by separating the code and data, typically with hardware features such as NX-bit
• Introduce randomization so the heap is not found at a fixed offset, typically with kernel features such as ASLR (Address Space Layout Randomization)
• Introduce sanity checks into the heap manager

Since version 2.3.6 the GNU libc includes protections that can detect heap overflows after the fact, for example by checking pointer consistency when calling unlink. However, those protections against prior exploits were almost immediately shown to also be exploitable.[2][3] In addition, Linux has included support for ASLR since 2005, although PaX introduced a better implementation years before. Also Linux has included support for NX-bit since 2004.

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

 

The whole point is to induce a situation that results in getting around all of these things, since nothing is perfect.

[hishnash]

2 hours ago, Dracarris said:

Also, Android users beware, if this is correct any image you receive on your favorite messaging app could be really bad news:

The scary part of core exploits like this for android is the number of users out there who will like never get any fix pushed out, and the possibly for an exploit to travel from application space to higher level in the system. For sample what process runs the image decode if you display a push notification (does that process have access to other apps notifications?), or what happens if you set a webP image as a file preview icon does this get rendering by the file browser (do you then controle the file browser)

[hishnash]

3 minutes ago, leadeater said:

uses the resulting pointer exchange to overwrite a program function pointer.

While you might be able to replace the function (return) pointer with another one if you have good HW security (signed pointers and read only executable memory) you cant just jump into your own data and run that code as that is loaded in non executable memory.   You would need to find a chain of functions that are already loaded as executable that will in effect run like an interpreter over your payload.  Or if your very lucky find a function that will attempt to load your payload as executable and then run it..  

[leadeater]

3 minutes ago, hishnash said:

 For sample what process runs the image decode if you display a push notification (does that process have access to other such notifications?) 

I would say yes, and that it's actually running with high level privileges as it is anyway. Wouldn't be any other way for this to happen, which from that persons assessment is the same thing as this, this being newer information discovery.

 

Quote

Apple released security updates for older iPhones to fix a zero-day vulnerability tracked as CVE-2023-41064 that was actively exploited to infect iOS devices with NSO's Pegasus spyware.

 

CVE-2023-41064 is a remote code execution flaw that is exploited by sending maliciously crafted images via iMessage.

 

As reported by Citizen Lab earlier this month, CVE-2023-41064 and a second flaw tracked as CVE-2023-41061 were used as a zero-click attack chain dubbed BLASTPASS, which involves sending specially crafted images in iMessage PassKit attachments to install spyware.

 

Quote

We refer to the exploit chain as BLASTPASS. The exploit chain was capable of compromising iPhones running the latest version of iOS (16.6) without any interaction from the victim.

So that's pretty scary.

[leadeater]

58 minutes ago, hishnash said:

While you might be able to replace the function (return) pointer with another one if you have good HW security (signed pointers and read only executable memory) you cant just jump into your own data and run that code as that is loaded in non executable memory.   You would need to find a chain of functions that are already loaded as executable that will in effect run like an interpreter over your payload.  Or if your very lucky find a function that will attempt to load your payload as executable and then run it..  

Let me put it this way, if there were true we wouldn't have this CVE or the one for BLASTPASS. Since it is happening and it's actively exploited is that not enough to say all that is needed?

[Dracarris]

50 minutes ago, leadeater said:

Never assume something like that is actually protecting you, stuff like that should in theory but that is the whole point of exploits like these. They are causing situations that get around them. This is not "just a buffer overflow". If it were then you wouldn't have needed to find 4 out of billions, any overflow would work which it doesn't.

Exceptional conditions aside, MMUs are an integral part of process isolation and therefore making sure each one stays within their allocated parts of physical memory?

Ofc the point of every exploit is to work around safeguards like these. That was not my question. It was why the safeguard did not do its job of protection.

 

All your quotes are nice and informative but don't answer my questions besides "duh it's a complicated exploit". It does not answer how it allows whatever process that does the webp processing to write into physical memory regions that do not belong to it. Doesn't really matter whether it's done via stack or heap, at some point all these accesses need to go through the MMU which performs hardware checks whether the respective physical address is allowed in the current thread context.

 

50 minutes ago, leadeater said:

An accidental overflow may result in data corruption or unexpected behavior by any process that accesses the affected memory area. On operating systems without memory protection, this could be any process on the system.

Bolded part is kinda essential to my question as the OSes that are vulnerable his exploit sure as hell do have memory protection (in the form of using MMUs and virtual memory which in turn is as well hardware-backed/supported).

 

Edit: Nvm, turns out I was thinking about a totally different thing, that is, how such a compromised webp process could execute code with root/kernel permissions or get data from other processes. Getting arbitrary external code to execute from within the allocated memory space of a process is ofc a different thing.

[LAwLz]

36 minutes ago, hishnash said:

The scary part of core exploits like this for android is the number of users out there who will like never get any fix pushed out, and the possibly for an exploit to travel from application space to higher level in the system. For sample what process runs the image decode if you display a push notification (does that process have access to other apps notifications?), or what happens if you set a webP image as a file preview icon does this get rendering by the file browser (do you then controle the file browser)

I am not 100% sure about this, but it seems likely that the Android libwebp package is part of com.android.media, and that has been a project mainline module since Android 10.

In other words, if your phone is ~3 years old or newer, Google should be able to update the library directly through the Play Store. No need to wait for OEMs to push out an update.

 

But that's quite a few "ifs".

[leadeater]

52 minutes ago, Dracarris said:

Doesn't really matter whether it's done via stack or heap, at some point all these accesses need to go through the MMU which performs hardware checks whether the respective physical address is allowed in the current thread context.

The quotes actually tell you how. If you have overwritten the memory that a pointer is referencing then you're going to hit that changed memory. The difference between Stack and Heap does actually matter here too though.

 

Quote

Heap is a region of process’s memory which is used to store dynamic variables. These variables are allocated using malloc() and calloc() functions and resize using realloc() function, which are inbuilt functions of C. These variables can be accessed globally and once we allocate memory on heap it is our responsibility to free that memory space after use. There are two situations which can result in heap overflow:

 

Quote

Stack is a special region of our process’s memory which is used to store local variables used inside the function, parameters passed through a function and their return addresses. Whenever a new local variable is declared it is pushed onto the stack. All the variables associated with a function are deleted and memory they use is freed up, after the function finishes running. The user does not have any need to free up stack space manually. Stack is Last-In-First-Out data structure. In our computer’s memory, stack size is limited. If a program uses more memory space than the stack size then stack overflow will occur and can result in a program crash

It matters a lot here if it's Stack vs Heap. If we are talking about memory exploits then this difference in my mind is crucial rather than unimportant.

 

What matters (I think?) is pointer consistency checking which is a thing but has also been found to be exploitable too.

 

52 minutes ago, Dracarris said:

Bolded part is kinda essential to my question as the OSes that are vulnerable his exploit sure as hell do have memory protection (in the form of using MMUs and virtual memory which in turn is as well hardware-backed/supported).

MMU is just Memory Management Unit, it doesn't have any actual meaning here like "Protects from XYZ" at all. Every MMU implementation is different across vendors and across their own generations of architectures. The fundamental purpose and function of a an MMU is to translate virtual addresses to physical address, not to provide security. The only security related function of an MMU is:

 

Quote

Modern MMUs generally perform additional memory-related tasks as well. Memory protection blocks attempts by a program to access memory it has not previously requested, which prevents a misbehaving program from using up all memory or malicious code from reading data from another program.

Which does not protect you from memory that has been maliciously changed that a program has accessed before.

 

Operating Systems with memory protection include Windows since 2003. But again that's not the point, everything is not perfect, that's why the exploits happen and also why they can, like this one, be so hard to find and identify.

 

Also I think the code execution is staying within the execution of libwebp and related processes and that is why most protections are not working as the attacker is finding a way to change the code that libwebp and related process themselves are executing.

 

Quote

Citizen Lab called this attack "BLASTPASS", since the attackers found a clever way to bypass the "BlastDoor" iMessage sandbox. We don't have the full technical details, but it looks like by bundling an image exploit in a PassKit attachment, the malicious image would be processed in a different, unsandboxed process. This corresponds to the first CVE that Apple released, CVE-2023-41061.

Above in reference to just the Apple vulnerabilities related to this but it's a good demonstration of how.

 

You're really not going to get anything super specific and clear from me since the details are not public, the link I have provided has the most details that exist. Everything else has not been disclosed and that was a decision made by those with the details. I do not have the in depth programming experience nor active red team activities to do any further explaining of this, and the last red team training I had was like 3 years ago anyway (well out of date to be useful now heh).

[Dracarris]

18 minutes ago, leadeater said:

It matters a lot here if it's Stack vs Heap. If we are talking about memory exploits then this difference in my mind is crucial rather than unimportant.

AFAIK stack based exploits usually work by manipulating the return address of the current function/process, so when it exits, it jumps to the attacker code. However, heap-based exploits in one way or the other seem to manipulate the return address of some kind of (m/re)alloc function. So, the first ingredient to both exploits, getting the CPU to jump to somewhere it's not supposed to jump to, is in both cases achieved through ra manipulation.

The difference then is where your malicious code actually resides in, where the heap-based approaches use some clever techniques to get the target process to allocate space for the attacker code and then copy it to there, then perform the ra exploit to execute it.

 

So this

18 minutes ago, leadeater said:

Also I think the code exception is staying within the execution of libwebp and related processes and that is why most protections are not working as the attacker is finding a way to change the code that libwebp and related process themselves are executing.

is kind of essential to my misunderstanding. It also limits the actual damage this exploit can do to whatever privileges the libwebp has (without an additional right escalation exploit).

[hishnash]

32 minutes ago, LAwLz said:

In other words, if your phone is ~3 years old or newer, Google should be able to update the library directly through the Play Store. No need to wait for OEMs to push out an update.

Many (non flagship) phones shipping today are shipping with 2 year old android so I would not be surprised if there were phones shipping 1 year ago that will not be covered.

 

I expect there real also a good number of apps that for some reason or other have opted to bundle thier own chromium and thus thier own version of this that will never get updates from the dev.... 

 

[wanderingfool2]

5 hours ago, leadeater said:

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

 

The whole point is to induce a situation that results in getting around all of these things, since nothing is perfect.

To an extent there is also a certain amount of backwards compatibility needed which keeps the doors open to future exploits.  Some older games which would render using the CPU dynamically change up their code to handle different events (using their own form of polymorphism back in the handwritten assembly instruction days...man was I surprised when I saw that happening when I was trying reverse engineering to fix a crash in an old game).

 

8 hours ago, leadeater said:

Like many vulnerabilities they aren't so simple and protections that are in place that are supposed to work don't always etc. Look at Side-Channel attacks, those worked with complete sandboxing and in cases even some forms of memory  and VM encryption etc.

I agree.  DEP is a good example of this, my CPU and system supports DEP, but I have a program that doesn't trigger it when modded but on other people's machines it triggers it instantly...despite DEP being there either something somewhere gets it's wires crossed.

 

To @Dracarris one of the reasons why hardware can't necessarily stop things is because it's in general a hard issue to actually stop without breaking things.  Imagine a game with a scripting language.  Ultimately the data stored there has to be translated/processed into machine code/behaviour (at least scripting languages that allow for more complex things...like executing commands/saving/writing files etc).  You can't necessarily inspect ever single read/write as well in memory to determine if it's valid as well, since you then are sacrificing performance.

 

One method to bypass some of the protections, like canary numbers, is crafting the overflow to  happen in a way that it writes the same canary number (if you somehow knew how to access  those numbers before).  The key is with a heap you can potentially find a function pointer at a fixed distance from where the overflow happens and overwrite it.  (Things such as vtable)

 

int main(...) {
...
}

char buffer[1024];
char* (*myfunc)(char*) = [some pointer to a function];

Now myfunc and memory for buffer would both be stored I think on the heap in this case and likely will be near each other.  So it's feasible that you could overflow buffer to write a bit into the myfunc variable which then you could have point towards your memory...in the eyes of any hardware inspector it doesn't know the size of memory that was put into the heap here.