You are still vulnerable to the WebP exploits, by the way

I've been writing a different blog post recently. I wanted to talk a bit about a project I'm making. I started it to make my work as a package maintainer easier, and so, I wrote a bit about why I think this matters.

Dynamic linking. If you install Chromium, Firefox, and ffmpeg on a typical Linux distribution, all of them will use the same, shared libwebp to show a webp picture. You only need one libwebp on your machine. And the list goes on! A build provided by Electron weighs 251.7 MB. The same version in Alpine Linux repositories is just 173.3 MB. (32.32 MB is saved by making support for more languages optional. Still >50 MB less). We don't have to copy nightmares in distributions.

Yes, I really mentioned libwebp specifically here. I opened the lists of dependencies, and thought this one is gonna be a nice, simple example that is actually true for all packages. Just before. For once, I hate being right.

If it can display an image, it can execute code

A buffer overflow issue was addressed with improved memory handling. This issue is fixed in macOS Monterey 12.6.9, macOS Big Sur 11.7.10, macOS Ventura 13.5.2, iOS 16.6.1 and iPadOS 16.6.1, iOS 15.7.9 and iPadOS 15.7.9. Processing a maliciously crafted image may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.

— CVE-2023-41064 on NVD, 2023-09-07

Heap buffer overflow in WebP in Google Chrome prior to 116.0.5845.187 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: Critical)

— CVE-2023-4863 on NVD, 2023-09-12T14:24:59.275Z

Google is aware that an exploit for CVE-2023-4863 exists in the wild.

— Chrome release notes, 2023-09-12T20:33:48.361Z

Security Vulnerability fixed in Firefox 117.0.1, Firefox ESR 115.2.1, Firefox ESR 102.15.1, Thunderbird 102.15.1, and Thunderbird 115.2.2.

CVE-2023-4863: Heap buffer overflow in libwebp

Opening a malicious WebP image could lead to a heap buffer overflow in the content process. We are aware of this issue being exploited in other products in the wild.

— Mozilla Foundation Security Advisory 2023-40, 2023-09-12

Acrobat Reader versions 23.003.20284 (and earlier), 20.005.30516 (and earlier) and 20.005.30514 (and earlier) are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

— CVE-2023-26369 on NVD

Adobe is aware that CVE-2023-26369 has been exploited in the wild in limited attacks targeting Adobe Acrobat and Reader.

— Adobe security bulletin APSB23-34

God's enterprisiest software got pretty loud fixes. Good. But the vuln is almost everywhere.

Do you use any Electron-based apps? Are they built by your software distribution? If not... do you think they even know what's happening?

Electron got a release for the current version a few hours later - on 2023-09-12T19:23:24Z (Chrome CVE got published on 2023-09-12T14:24:59.275Z). But you'd need to read Chrome release notes to know this. The Electron changelog entry was:

Other Changes:

Updated Chromium to 116.0.5845.188. #39828

Yes. Really. No other announcements either. The vulnerability is only mentioned in release notes for older major (but still supported) versions, where the fix got backported.

If you have an Electron app, fixed version cheat sheet:

Signal followed a few more hours later, with their release of Signal Desktop on 2023-09-13T06:04:12Z. If we're at the changelogs, this one was as descriptive as all of their patch notes:

• Keep tabs on your calls with the new calls tab. Start a new call or return a call that you missed without having to find the corresponding chat. Now you can say hello with your voice without also saying goodbye to the unread marker for messages in that thread.

And that would be the end of developer self-realization in this post.

In case of Element Desktop, a tranny that doesn't sleep at night had realized first, and it had submitted a pull request on 2023-09-15T02:17:03Z. That's almost 3 whole days later. This was then released on 2023-09-15T11:23:33Z.

(The tranny is the author of this text. Hi, reader! Don't mind me, just reclaiming some slurs.)

More friction? Fuck yes. If you use Element Desktop from Flathub, that's even more waiting. Flathub simply downloads tarballs with builds. There is a bot that downloads a webpage and runs a regex over it. It has detected the release and made a PR with the update on 2023-09-15T13:13:36Z. Then, the PR has been merged manually on 2023-09-15T15:10:06Z. That has finally triggered a rebuild (or rather, re-repack). The notice about a security fix has disappeared on the way, and this update on Flathub is not marked with a higher urgency (as is an option on there), but it's there.

To be clear, Element had a good response once they finally heard about it. But it still took days in friction between multiple projects having to fix publicly known vulnerabilities. This system of distribution is just broken.

Another real chat app has released the security fix on the beta channel, and everyone went on a weekend. The Jira ticket for this states "No testing required", but, oh well.

Similar stories with Flutter. In this case, you'd need to know where to find these release notes - they're on a special GitHub Wiki page, separate from the other release notes. (The fixed release is 3.13.4.) Now just wait for all app developers to release it on Google Play...

This doesn't have to be broken like this.

Software distributions work. In Alpine Linux, where I'm a contributor, a hotfix got merged into edge on 2023-09-13T17:42:01.841Z, and then backported to earlier versions. That's just what a distribution does. The information flow is free here. In this case, Alpine has followed NixOS. Another time Arch will follow Alpine. But that's ok, we don't like having secrets.

The hotfix I mentioned was merged to the libwebp package. It's a shared object getting reused by other packages. Once you run apk upgrade, the old /usr/lib/libwebpdemux.so.2.0.14 on your disk gets replaced with a new one. Also, Chromium, Electron, Firefox, Flutter, Thunderbird, all depend on it. You don't have to rebuild or redownload all of them (and the apps they're a part of). Better. As a package maintainer for 2 of these, I didn't even have to know about it. Cool, isn't it?

On a sidenote. I've submitted the changes adding an option to unbundle dependencies back to Flutter, back when I made them.

We can't do this.

Most of these libraries do not provide stable ABI. And Flutter does not guarantee that it plays nicely - sometimes we use private API even though we're not supposed to.

If you arbitrarily change the versions of these dependencies, you could get anything from reduced performance to completely broken/crashing binaries.

I keep applying that patch in Alpine anyway. Guess what. It works without issues, and we got this patched earlier as a consequence.