| Age | Commit message (Collapse) | Author |
|---|
|
(cherry picked from commit 41b05f954882313131a75ccbc53c1e373a915d38)
|
|
On Windows, if an application is registered as an URL handler like this:
HKEY_CLASSES_ROOT
https
URL Protocol = ""
[...]
shell
open
command
(Default) = ".../qutebrowser.exe" "%1"
one would think that Windows takes care of making sure URLs can't inject
arguments by containing a quote. However, this is not the case, as
stated by the Microsoft docs:
https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa767914(v=vs.85)
Security Warning: Applications that handle URI schemes must consider how to
respond to malicious data. Because handler applications can receive data
from untrusted sources, the URI and other parameter values passed to the
application may contain malicious data that attempts to exploit the handling
application.
and
As noted above, the string that is passed to a pluggable protocol handler
might be broken across multiple parameters. Malicious parties could use
additional quote or backslash characters to pass additional command line
parameters. For this reason, pluggable protocol handlers should assume that
any parameters on the command line could come from malicious parties, and
carefully validate them. Applications that could initiate dangerous actions
based on external data must first confirm those actions with the user. In
addition, handling applications should be tested with URIs that are overly
long or contain unexpected (or undesirable) character sequences.
Indeed it's trivial to pass a command to qutebrowser this way - given how
trivial the exploit is to recreate given the information above, here's a PoC:
https:x" ":spawn calc
(or qutebrowserurl: instead of https: if qutebrowser isn't registered as a
default browser)
Some applications do escape the quote characters before calling
qutebrowser - but others, like Outlook Desktop or .url files, do not.
As a fix, we add an --untrusted-args flag and some early validation of the raw
sys.argv, before parsing any arguments or e.g. creating a QApplication (which
might already allow injecting Qt flags there).
We assume that there's no way for an attacker to inject flags *before* the %1
placeholder in the registry, and add --untrusted-args as the last argument of
the registry entry. This way, it'd still be possible for users to customize
their invocation flags without having to remove --untrusted-args.
After --untrusted-args, however, we have some rather strict checks:
- There should be zero or one arguments, but not two (or more)
- Any argument may not start with - (flag) or : (qutebrowser command)
We also add the --untrusted-args flag to the Linux .desktop file, though it
should not be needed there, as the specification there is sane:
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables
Implementations must take care not to expand field codes into multiple
arguments unless explicitly instructed by this specification. This means
that name fields, filenames and other replacements that can contain spaces
must be passed as a single argument to the executable program after
expansion.
There is no comparable mechanism on macOS, which opens the application without
arguments and then sends an "open" event to it:
https://doc.qt.io/qt-5/qfileopenevent.html
This issue was introduced in qutebrowser v1.7.0 which started registering it as
URL handler: baee2888907b260881d5831c68500941937261a0 / #4086
This is by no means an issue isolated to qutebrowser. Many other projects have
had similar trouble with Windows' rather unexpected behavior:
Electron / Exodus Bitcoin wallet:
- http://web.archive.org/web/20190702112128/https://medium.com/0xcc/electrons-bug-shellexecute-to-blame-cacb433d0d62
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000006
- https://medium.com/hackernoon/exploiting-electron-rce-in-exodus-wallet-d9e6db13c374
IE/Firefox:
- https://bugzilla.mozilla.org/show_bug.cgi?id=384384
- https://bugzilla.mozilla.org/show_bug.cgi?id=1572838
Others:
- http://web.archive.org/web/20210930203632/https://www.vdoo.com/blog/exploiting-custom-protocol-handlers-in-windows
- https://parsiya.net/blog/2021-03-17-attack-surface-analysis-part-2-custom-protocol-handlers/
- etc. etc.
See CVE-2021-41146 / GHSA-vw27-fwjf-5qxm:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41146
https://github.com/qutebrowser/qutebrowser/security/advisories/GHSA-vw27-fwjf-5qxm
Thanks to Ping Fan (Zetta) Ke of Valkyrie-X Security Research Group
(VXRL/@vxresearch) for finding and responsibly disclosing this issue.
(cherry picked from commit 8f46ba3f6dc7b18375f7aa63c48a1fe461190430)
# Conflicts:
# qutebrowser/qutebrowser.py
# tests/unit/test_qutebrowser.py
|
|
This is a continuation of the previous commit for #5403. The tests are split up
from the commit itself so that the fix can be backported with less conflicts.
See #5403
(cherry picked from commit 45a2be3f9f32f900c0b567998433d43055f722e2)
|
|
Without this change, we only set a flag when a certificate error occurred.
However, when the same certificate error then happens a second time (e.g.
because of a reload or opening the same URL again), we then colored the URL as
success_https (i.e. green) again.
See #5403
(cherry picked from commit 021ab572a319ca3db5907a33a59774f502b3b975)
|
|
|
|
|
|
|
|
Since d741bdf2f92b9dcf897b15c9d850fff6442f1cf7 I've been seeing a lot more
segfault reports with this stacktrace:
File ".../config/websettings.py", line 88 in test_attribute
File ".../browser/webengine/webenginetab.py", line 1376 in _error_page_workaround
File ".../app.py", line 154 in qt_mainloop
I'm not sure what's going on... However, getting the JavaScript status earlier
should get us closer to how this code worked before.
(cherry picked from commit d9b915bc50653ce8d50ffa00967f815244e6e57b)
|
|
|
|
|
|
See https://github.com/mhammond/pywin32/issues/1256
(cherry picked from commit 732ca70210c5664f871d7b0a987a41252ed4ac4f)
|
|
It looks like there are two APIs for screen sharing:
===============================================================================
Old, unstandardized
-------------------
navigator[.mediaDevices].getUserMedia(
{video: {mandatory: {chromeMediaSource: 'screen'}}, ...)
Permission enum added in Qt 5.10. Seems to be behind a feature switch
(--enable-usermedia-screen-capturing) ever since it's been added to Chromium.
Demo pages:
https://html5-demos.appspot.com/static/getusermedia/screenshare.html
https://www.webrtc-experiment.com/screen-sharing/
New
---
navigator.mediaDevices.getDisplayMedia(...)
Added in Chromium 72, i.e. Qt 5.13:
https://www.chromestatus.com/feature/6744724455030784
Demo page:
https://www.webrtc-experiment.com/Pluginfree-Screen-Sharing/
===============================================================================
While the old API was in theory supported since Qt 5.10, it's unlikely to ever
have worked, as it was hidden behind the feature switch. However, I'm not aware
of any crashes related to it, so let's just let Qt handle things in that case.
With Qt 5.13, the new API is supported, however, using it causes a segfault on
Qt 5.13.0 and 5.13.1: https://bugreports.qt.io/browse/QTBUG-78016
Fix for Qt 5.13.2: https://codereview.qt-project.org/c/qt/qtwebengine/+/276998
Given those circumstances, disable screen capturing automatically and log a
warning on Qt 5.13.0 and 5.13.1.
With Qt 5.13.2, screen capturing doesn't crash anymore and works fine on
Windows, but does nothing on Linux. Looks like this is getting fixed in
Qt 5.14:
https://bugreports.qt.io/browse/QTBUG-80055
https://codereview.qt-project.org/c/qt/qtwebengine/+/281549
(cherry picked from commit a733fa9fd0af5438057fc791f6bd78b8a75a8ef5)
|
|
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882805
See #5078, #3773
(cherry picked from commit d741bdf2f92b9dcf897b15c9d850fff6442f1cf7)
|
|
(cherry picked from commit d51ea32149085e5d33a197f7a2d1adf95545f4cf)
|
|
(cherry picked from commit 8a1768a41aa80a3565d0e48aacde60c7586f6df8)
|
|
(cherry picked from commit 7eee69845348e7f39930ac3a2fa4330136334566)
(cherry picked from commit a33770d50e1dad2f5b453a69cb00a2f5190ee8a7)
|
|
|
|
(cherry picked from commit 8ccea6e8000dbab70b66633167d3cea86e4de26e)
|
|
|
|
(cherry picked from commit 9520fc2d315507eb4733f8f688bbb66e04314a7e)
|
|
(cherry picked from commit 1ed80cd3533eca636e3279515160ce03d0448d09)
|
|
Using config.bind(key, None) in a config.py file never was supposed to be
possible. However, it worked by accident until v1.7.0, where it then broke
because of 9ed6aaaa1646fad0710ba28bf12bd8eb9e011a72.
Also, note that :config-py-write also emitted such invalid lines, which was
fixed in v1.8.0 in #4949.
(cherry picked from commit 2033ed1955b642cbcd2bc4ea88d361c340fb3d38)
|
|
My password generator found this one.
(cherry picked from commit a6b9e9b2a9a6af8402becf9a7950c34f6e79d627)
|
|
(cherry picked from commit a3ec34b55db4ee46f3cb67a277b84f335ae5c992)
|
|
|
|
|
|
This reverts commit 548b5a17d72b42df997055c945c5e42e80b31af3.
This reverts commit fe32e00a4e1b5a7cfd49638501a072df243636c2.
Due to QTBUG-77364 (broken keyboard focus), we can't upgrade to qtbase 5.13.1.
However, with 5.13.0 (and QtWebEngine 5.13.1), we run into two more issues:
- Segfaults in QQuickWindowPrivate::updateDirtyNode() when logging into a
Google account (especially on macOS).
- Qt 5.13.0 with the old PyQt5 exit scheme segfaults on exit on Windows.
However, pyqt5_enable_new_onexit_scheme() was added in PyQt 5.13.1.
See https://bugreports.qt.io/browse/QTBUG-77364
See https://www.riverbankcomputing.com/news/pyqt-5131
Reopens #4918
(cherry picked from commit c397e9326b6d323f41e1f26157e113d792c5895b)
|
|
(cherry picked from commit 4f76266a4b961e8db7df8dfea084678a2e9dd39e)
|
|
|
|
|
|
|
|
|
|
|
|
See #4919
|
|
|
|
|
|
This reverts commit 56a2c5050892ad93492e217a21df77b6cc0013a8.
Fixes #4918
|
|
|
|
|
|
|
|
|
|
See #5032
|
|
|
|
|
|
According to https://sqlite.org/rescode.html this error should rarely happen:
The SQLITE_PROTOCOL result code indicates a problem with the file locking
protocol used by SQLite. The SQLITE_PROTOCOL error is currently only returned
when using WAL mode and attempting to start a new transaction. There is a
race condition that can occur when two separate database connections both try
to start a transaction at the same time in WAL mode. The loser of the race
backs off and tries again, after a brief delay. If the same connection loses
the locking race dozens of times over a span of multiple seconds, it will
eventually give up and return SQLITE_PROTOCOL. The SQLITE_PROTOCOL error
should appear in practice very, very rarely, and only when there are many
separate processes all competing intensely to write to the same database.
However, in practice, this happens for some users during the sqlite
initialization (while turning on WAL). Since we can't do anything, this
shouldn't be handled as error.
|
|
Scheduled weekly dependency update for week 38
|
|
|
|
|
|
|
|
|
