Update the WebP library to the latest version to prevent possible vulnerability attacks

[v_kyr]

A number of vulnerabilities in Google's WebP image format have recently become known that allow attackers to trigger memory errors (heap buffer overflow) in unspecified ways. This usually means that malicious code can get onto systems and attackers can completely compromise computers. – Therefore, it makes sense to update the Webp library accordingly to prevent and close this WebP gap for Affinity products.

[myclay]

I wonder if MSIX sandboxing helps here or not?

[CLC]

On 9/15/2023 at 10:09 AM, myclay said:

I wonder if MSIX sandboxing helps here or not?

Sadly, not at all.

Thank you for mentioning this, @v_kyr, what a shame you posted this into Feedback section instead of bug section though.

Also, severity of this bug is so serious that Serif should issue an update to the whole V1 line as well...

Honorable mention: @Patrick Connor

[v_kyr]

7 hours ago, CLC said:

what a shame you posted this into Feedback section instead of bug section though

First I wanted to place it into the bug section, but then thought Ok it's usually not an Affinity own bug but instead more a Google third-party used library (libwebp) security hole (bug) which can lead to vulnerability attacks.

Also so far didn't recherched, if the yet new released Affinity v2.2 versions do include a more recent (fixed) libwebp version here or not (?). If not they should update that one accordingly!

[Patrick Connor]

It's fine being here. I have linked your request to the developer report, which is under consideration already.

[ATP]

https://nvd.nist.gov/vuln/detail/CVE-2023-5129

Google has given this vulnerability a 10.0 base score, something basically never seen.

[v_kyr]

On 9/27/2023 at 3:26 PM, ATP said:

https://nvd.nist.gov/vuln/detail/CVE-2023-5129

Google has given this vulnerability a 10.0 base score, something basically never seen.

Yes, things obviously get now another dimension, the more becomes known about the libwebp security hole. - In order to be on the more safe & secure side here, any app which makes use of an older libwebp implementation should be updated to the newest release accordingly.

The whole reminds me somehow to the Apache Log4j Security Vulnerabilities, where thousends of server side apps (internal & external ones) used the Log4j API (for very long times) without knowing about the security hole in that one. Afterwards a lot of Java based services had to be changed world wide (step for step) in order to prevent the door opened by Log4j. - I see now the same coming for libwebp related software here!

.....................

Countless applications affected: Chaos at WebP gap

A security gap in the WebP graphics format affects significantly more applications beyond Google's Chrome.

Countless applications show pictures in Google WebP format. A weak point in the graphic format accordingly concerns all applications that use the format. In the beginning, Google only assigned the gap to the in -house web browser Chrome.
New gap = old gap?

In the meantime, however, Google has corrected itself and submitted the new entry CVE 2023-5129 with a critical classification (CVSS Score 10 out of 10) for the old security gap (CVE 2023-4863 "High").

However, this was declared invalid by Google after six hours. The reason is that the new entry twice with the old entry. For this purpose, the old entry has now been added that the gap in addition to Chrome also affects the complete Libwebp library that use many applications.

What an attack could look like is so far unclear. In the context of web browsers there is always talk of prepared HTML websites. It sounds like visiting a website with a malicious webp graphic can initiate an attack. If an attack is successful, malicious code gets to systems.
Affected applications

These include browsers such as Edge and Firefox, Linux distributions such as Debian and Ubuntu and applications such as LibreOffice, Slack and Signal Desktop. In addition, many applications that rely on the electron framework are affected. A security researcher on GitHub currently collects a list of vulnerable electron apps. The Electron version 1.3.2, on the other hand, should be secured.

The list of vulnerable applications is therefore long and not all security updates have been published. So users should look for patches and quickly install them. Safe expenses have already been published for Firefox, Thunderbird and Tails.

On X, a security researcher brings the webp gap in connection with the BlastPass baptized attacks (CVE-2023-41064 "high") to Apple systems by the controversial security company NSO Group. There are currently no further details.

[v_kyr]

The libwebp library version 1.3.2 is the actual fixed one!

[Affinity Info Bot]

The issue "Affinity apps affected by the latest exploit in Google's WebP Library: CVE-2023-4863" (REF: AF-207) has been fixed by the developers in internal build "2.2.1.2052".
This fix should soon be available as a customer beta and is planned for inclusion in the next customer release.
Customer beta builds are announced here and you can participate by following these instructions.
If you still experience this problem once you are using that build version (or later) please reply to this thread including @Serif Info Bot to notify us.

[Andreas Scherer]

10 hours ago, Serif Info Bot said:

The issue (REF: AF-207) has been fixed and is planned for inclusion in the next customer release.

Will there also be a rebuilt Affinity V1? (1.10.7 or 1.11? – also in light of reported issues with Sonoma.)

[Patrick Connor]

On 10/6/2023 at 8:50 PM, Andreas Scherer said:

Will there also be a rebuilt Affinity V1? (1.10.7 or 1.11? – also in light of reported issues with Sonoma.)

We are planning to address a few issues that affect 1.10.6 on Sonoma, but this the code change in 2.2 for this was significant, and we have not decided whether the change is safe for 1.10.x, whose codebase is very different to 2.2

[v_kyr]

46 minutes ago, Patrick Connor said:

... and we have not decided whether the change is safe for 1.10.x, whose codebase is very different to 2.2

Give it some internal test flight, as far as the libwebp function calls haven't changed much at all and the lib still compiles (can be build) with older macOS version compatibility options, there are chances that it can be replaced for v1 apps too. - Since otherwise the v1 apps won't be protected from these possible vulnerabilities.

[Patrick Connor]

18 minutes ago, v_kyr said:

Give it some ....

er thanks