| Age | Commit message (Collapse) | Author |
|---|
|
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)
|
|
|
|
(cherry picked from commit 74cf64a063a12a08e8979e2145b3cf0394bf2abd)
|
|
(cherry picked from commit 78d4a9d41b0f435bf379ec4b06e3cbcb3d30c207)
|
|
(cherry picked from commit 7961cf73553847ea265a388b736fffac77dae66a)
|
|
(cherry picked from commit 92178e8152e681fac4d95382978e9391b5ca66d5)
|
|
|
|
|
|
(cherry picked from commit b04f99bcfce00c72fe7b8e59d76012141a8cb02d)
|
|
|
|
(cherry picked from commit efcb3798729b6dedbf63baa443837720df63ce29)
|
|
(cherry picked from commit 49e858e7d44b6e3ba24a388e2bdbffeb88d9adb8)
|
|
(cherry picked from commit 909230a8acd0423a85322602453cddad372072d8)
|
|
See https://github.com/ArniDagur/python-adblock/issues/28
Follow-up to de4fff386646b305890998b4dff660fe3127026f
(cherry picked from commit ffdee8534d69d5f39d49d617b9f47fc4b7b7d86a)
Also updates adblock from 3b76a0d4b9613b74b104caec28ecda1445f084a5
|
|
|
|
|
|
|
|
|
|
This reverts commit 3284ec900e42b279bc3bc40593d7356ab1e3f9b0.
Not needed as most gopass versions do this when stdout is a pipe, but it
interfers with reading the username from the secret.
See the discussion in #6323 for more detail, and #5972 for the original
PR.
|
|
needed because pytest-cov requires coverage[toml]
|
|
|
|
|
|
Co-authored-by: Florian Bruhin <me@the-compiler.org>
|
|
Update dependencies
|
|
See https://github.com/hjwp/pytest-icdiff/pull/20
|
|
|
|
arount the OTP token is omitted
|
|
See #6298
|
|
See #6298
|
|
userscripts: keepassxc: Fix broken link
|
|
|
|
|
|
|
|
See #6269
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The mozilla/readability library doesn't output a body by default.
So, let's add one in the header and plug the result in.
|
|
Until per-domains stylesheets are implemented, there is no way to
apply style to the readability page only. With this patch, you can
just use the global setting `content.user_stylesheets` by writing
a more specific CSS selector. For example:
body.qute-readability {
font-family: Libertinus;
font-size: 1.2em;
text-align: justify;
}
will change the font and text alignment of the readability page,
without altering the style of other websites.
|
|
|
|
|
|
|
|
|
|
This reverts commit 43ff51fe7b47a7f534b9d88545364d2c84e6e6d6.
Now fixed upstream.
|
|
See https://github.com/nedbat/coveragepy/issues/1129
|
|
|
|
|
