Webp Virus, fears, nightmares, suggestions, or exodus from the internet?

[Dixel]

NHS Digital and NHS England already declared it to be "medium".

https://digital.nhs.uk/cyber-alerts/2023/cc-4376

CVE-2023-4863 

Threat ID: CC-4376

Threat Severity: Medium

Published: 12 September 2023 2:03 PM

[Cocodile]

4 hours ago, Sampei.Nihira said:

For you who use browsers that are probably not already patched, I am including the fix that is valid for Chromium-based browsers:

https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a

https://github.com/webmproject/libwebp/releases/tag/v1.3.2

I don't see how to apply it, it's only source code there. Did I miss something?

[j7n]

I don't know who installs image codecs at the OS level. Is there even such a thing? Microsoft had FLT codecs that only worked in Office.

We probably won't see webP files being distributed outside of the web for images like album artwork in hopes of crashing Foobar2000. Any webp file I open on my computer in IrfanView I would have intentionally saved because it had real content.

I've tried disabling WebP in my browsers in the past because usually it is transcoded from JPEG with an additional quality loss, but then I sometimes got no images at all.

[Cocodile]

3 hours ago, j7n said:

I don't know who installs image codecs at the OS level.

I'll tell you, it's Icaros Property Handler and Icaros Thumbnail Provider, they included in K-Lite Codec Pack, for example.

[Guest]

45 minutes ago, Cocodile said:

I don't see how to apply it, it's only source code there. Did I miss something?

When I provided Roytam1 with Thunderbird's OAuth authentication support code, it was possible to get it into MailNews.

My area is IT Security,you have to ask the web browsers developers.

Edited September 19, 2023 by Sampei.Nihira

[Guest]

1 hour ago, Dixel said:

" security fix for lossless decoder"  lossless?

What was the problem in the WebP library?

The root of the issue lies within the "BuildHuffmanTable" function which was first introduced in 2014, the function is used to verify if the data is accurate. The vulnerability can occur when more memory is allocated if the table isn't sufficiently large for valid data. The commit that introduces the fix can be seen here.

The original code optimized a Huffman decoder that uses a common technique: it reads several bits ahead to determine how many bits to consume and what symbol to decode. The older version utilized lookup tables for short symbols, while longer ones required a more complex graph traversal. The newer version streamlined this process by employing an array of lookup tables. Each entry in this table contains details about bits and values, and if the number of bits surpasses a certain limit, the value is interpreted differently.

The new version determined the maximum number of entries by counting symbols. However, because the Huffman tree comes from an untrusted source, situations could arise where the number of bits is excessively large. The VP8 Lossless allows up to 15 bits, which means the largest table can have many entries, more than it should. Interestingly, while there was a mode in the code to only calculate the table size, it was not used, and a fixed size was assumed, leading to potential overflows.

The reason behind these changes was to optimize the Huffman decoding step, a crucial and computationally intensive part of compression formats. Though the optimization technique is recognized, longer codes are generally not given priority because they don't often appear. The original code update argued against this belief, and it was accepted.

The issue highlighted isn't something that just using a memory-safe language could prevent. It's a unique scenario where avoiding overflow checks is desired. However, while the actual solution didn't change the function, ensuring the safety of the tight loop remains critical. Wrong justification for such safety measures can lead to problems.

 

Google has confirmed the existence of an exploit for CVE-2023-4863 in the wild.

If the unpatched browser is put on the Anti-Exploit list, it almost certainly turns out to be protected.
Theoretically if a malformed web page is encountered with the exploit the web browser should shut down.
At least this would be the behavior with WD exploit protection.

[Guest]

If anyone wants to check whether their browser processes web images in the WebP format:

 

https://developers.google.com/speed/webp/gallery1?hl=en

 

Have a good continuation of the day to you all.

Edited September 19, 2023 by Sampei.Nihira

[Tripredacus]

22 hours ago, Dixel said:

At the OS level, uninstall all third party codecs, if you have any, ASAP. Any codec sets that add webp codec to the OS (K-lite and the such). Also, I suggest to uninstall all VP8 codec iterations, since it's basically the same with webp.

For example, the famous French VLC player doesn't need any codecs in the system, it has its own.

That is the application level, not the OS level.

[Anbima]

On 9/18/2023 at 3:17 PM, Dixel said:

What does the test page tell you? Post the screenshot please.

 

I get the following header:
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/apng,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

and on the following page the webP images are displayed:
https://developers.google.com/speed/webp/gallery1?hl=en

[UCyborg]

Web server can send whatever it wants regardless of what that header says. You'd have to disable WebP decoding functionality inside the browser, which in case of Chromium based browsers probably means analyzing the disassembled code and altering it so decoding routines don't run. Unless you have the source code which it's compiled from, in that case it could be done without hacking the binaries.

Edited September 19, 2023 by UCyborg

[NotHereToPlayGames]

6 hours ago, Anbima said:

https://developers.google.com/speed/webp/gallery1?hl=en

 

4 hours ago, UCyborg said:

Web server can send whatever it wants regardless of what that header says.

 

Confirmed, sadly.  In newer versions of Ungoogled Chromium, there is a flag to set your "accept" header (ie, for those that don't use Proxomitron).

The "gallery test page" displays these webp images whether the "accept" header indicates the browser can render webp or not.

But I also wonder if this "gallery test page" is even sending true .webp images because IE8 does not support webp and this "gallery test page" shows these .webp images even with an IE8 useragent and client hints disabled.

Though I am also on Win10 at the moment so unsure if that is playing a factor.

[UCyborg]

I'm pretty sure it would take some effort implement fallback to as far as IE8 goes. Been years since I messed with any web server and I'm sure with the simple configuration, you put whatever you want in the HTML and it'll serve it in any case as-is.

[Dixel]

16 hours ago, Tripredacus said:

That is the application level, not the OS level.

 

You are right technically speaking, but the sneaky K-Lite embeds itself such deep into OS, for example it suggests to replace/disable the original Microsoft AVC codec, when you run the installer with "advanced" settings. After the installation, all apps will now use the K-lite codecs, not the system ones. Even the windows player! @Cocodile is right. Integrating the preview of webp into explorer is the best way to get infected.

[Dixel]

7 hours ago, NotHereToPlayGames said:

 

 

Confirmed, sadly.  In newer versions of Ungoogled Chromium, there is a flag to set your "accept" header (ie, for those that don't use Proxomitron).

The "gallery test page" displays these webp images whether the "accept" header indicates the browser can render webp or not.

But I also wonder if this "gallery test page" is even sending true .webp images because IE8 does not support webp and this "gallery test page" shows these .webp images even with an IE8 useragent and client hints disabled.

Though I am also on Win10 at the moment so unsure if that is playing a factor.

Yep, looks like you're right, I don't see any links to the actual webp they declare to "test", I switched to basic HTML to show it, but for some reason it is now in German!

[Dixel]

17 hours ago, Sampei.Nihira said:

What was the problem in the WebP library?

No, I meant it's served highly compressed, not lossless. That's the whole idea behind the usage of webp, to save the bandwidth, and to hell with the quality.