| 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)
|
|
In some scenarios (which I can't seem to reproduce), the URL we get in
shared.feature_permission is an invalid one.
In that case, we set "urlstr = None", but that means we call message.* with
url=None but option=... set. Since that's invalid usage (we can't set a
per-domain option without knowing the URL) it bails out, causing a crash.
(cherry picked from commit 068f3ded896aa70cbc644674803cdeb6389d6561)
|
|
(cherry picked from commit 81a5ada67f71af5cd412a16552843a1db0258a4d)
|
|
Looks like we need some patching again nowadays...
This reverts commit 7763287b100dd4b15135bc40957e6c3bcd1b5e42.
(cherry picked from commit d37843d13759630a46213373a75144b147cbeba4)
|
|
See https://github.com/pyinstaller/pyinstaller/issues/4293
and https://github.com/gridsync/gridsync/pull/236/commits/0abf8e7363cc8c2a10a0263e6dcceb3be1c07022
(cherry picked from commit e58aa9c8ae37398dd09b0bf83dc4df90b10827b5)
|
|
(cherry picked from commit 730018e37e19878681b1ae7c92afb38cd02e7c96)
|
|
(cherry picked from commit dfabbff63b1fba3c86a921c306883bfe39df2bdd)
|
|
(cherry picked from commit 412dd58b0b821199188e8cebedbb0e78204ccb33)
|
|
(cherry picked from commit 9cba5a074aff691331ae00f20c6c3e8de42ac87b)
|
|
(cherry picked from commit 09ff9a87a5621b7c105dad7edef2e66853c50978)
|
|
(cherry picked from commit d7e68a5326de8dbe49004faa615225ec47e578b4)
|
|
|
|
|
|
|
|
|
|
Otherwise, temporary files and processes get cleaned up after the test is
finished, leading to warning messages.
|
|
|
|
|
|
Fixed in tox v3.4.0 (2018-09-20)
|
|
Mainly due to https://bugreports.qt.io/browse/QTBUG-76913
|
|
See #4917, #4795
|
|
Fixes #4899
|
|
|
|
|
|
|
|
See #4657
|
|
|
|
In PyQt, QWebEngineClientCertificate is guarded by "%If (PyQt_SSL)", so it
might not be available in all cases.
|
|
|
|
|
|
See #4911, #4221
Fixes #4910
|
|
See #4221
|
|
Let's stay with 5.12 for PyPI-installed virtualenvs for now, see:
https://bugreports.qt.io/browse/QTBUG-76913
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Using lxml means rewriting the file, which loses comments.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
