[qutebrowser] CVE-2022-1096 in Chromium/QtWebEngine and CVE-2022-25255 in Qt

[Florian Bruhin]

Hi,

Now that the mailinglist is up and running again, some information about
two CVEs which aren't in qutebrowser, but affecting it:

# CVE-2022-1096: Type Confusion in V8 (Chromium's JS engine)

Late last week, news dropped about a high-severity vulnerability in
Chromium, of which "Google is aware that an exploit for CVE-2022-1096
exists in the wild.":

https://chromereleases.googleblog.com/2022/03/stable-channel-update-for-desktop_25.html
https://www.forbes.com/sites/daveywinder/2022/03/26/google-confirms-emergency-security-update-for-32-billion-chrome-users-attacks-underway/

I contacted Qt's security contact for more information about this. I
think they have a Chromium security contact so they can get non-public
details. This is still a work in progress, but from what I could find
out so far:

- QtWebEngine, and thus qutebrowser, is likely affected too.
- A first fix was integrated to the 87-based branch here:
  https://codereview.qt-project.org/c/qt/qtwebengine-chromium/+/403222
- From what I understand, that's not a complete fix yet:
  https://github.com/v8/v8/commit/a2cae2180a7a6d64ccdede44d730c9fbba690fb7
- Apparently there was a consensus to delay the (already almost
  released) Qt 5.15.9 to get the fix(es) in.

If the second/full fix doesn't make it, I plan to ask the Archlinux
maintainer to backport the patches. For other distributions, you might
want to ask them to do the same.

As usual, some stable distributions (Debian Stable, Ubuntu LTS and Linux
Mint, to name a few) likely will continue shipping a heavily outdated
QtWebEngine with no security patching:
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security

## qutebrowser via virtualenv and official releases

Unfortunately, things also aren't looking great for macOS/Windows
releases of qutebrowser and virtualenv installs, though the situation
there is more temporary: After QtWebEngine 5.15.2, Qt 5.15 releases
unfortunately turned commercial-only:
https://www.qt.io/blog/qt-offering-changes-2020
https://lists.qt-project.org/pipermail/development/2021-January/040798.html

While there are still source releases of QtWebEngine 5.15.* (due to
third-party LGPL code from Chromium), there have been no binary
releases, and thus also no updated PyQt binary wheels. It would
theoretically be possible to build QtWebEngine from source, but doing so
on Windows and macOS is especially painful, so I'm afraid I'm not going
to do so.

If you're using qutebrowser via a virtualenv, you might instead want to
consider using a Flatpak install until Qt 6 support lands. Doing so will
give you a newer QtWebEngine, which will hopefully also include the
patch once it's released upstream.

## State of Qt 6 support

This whole situation will resolve once qutebrowser supports Qt 6 fully,
which offers an updated QtWebEngine (including binary releases!) since
Qt 6.2 in September. This isn't quite ready yet, but my top priority
after getting a v2.5.0 release out. I already use the "qt6-test" branch
as a daily driver since quite a while myself, and it's usable, though a
little buggy still. More information here:
https://github.com/qutebrowser/qutebrowser/issues/5395

Soon there will be an updated "qt6" branch based on the current master,
and a call for testing things before they get merged at some point. Stay
tuned!

# CVE-2022-25255: QProcess running processes from current directory

This one is less severe, but still something to be aware of: Earlier Qt
versions had a security issue causing QProcess to run an executable from
the current directory if it wasn't found system-wide:
https://lists.qt-project.org/pipermail/announce/2022-February/000333.html

This affects the :spawn command in qutebrowser. I added a workaround
which will be released as part of v2.5.0:
https://github.com/qutebrowser/qutebrowser/commit/982c3f1fbd54d3713ba31bab4c4ff8f748367df1

However, I believe the impact with typical qutebrowser usage is low:
Normally, qutebrowser is run from a fixed location (usually the users
home directory), and `:spawn` is not typically used with executables
that don't exist. The main security impact of this bug is in tools like
text editors, which are often executed in untrusted directories and
might attempt to run auxiliary tools automatically.

...and another long mail finished. Sorry for the wall of text :)

Florian

-- 
            me at the-compiler.org | https://www.qutebrowser.org 
       https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
       GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
             I love long mails! | https://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20220330/7f2b9a83/attachment.asc>