| 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)
|
|
(cherry picked from commit ef94fb86261418bf97f3a8d5433fa647f38a1006)
|
|
(cherry picked from commit 32c2f9b24089ab21b502ed3224f94b5428694808)
|
|
(cherry picked from commit ceb1465bd300ceba6e4c6a7c601b3c1f76e5de1b)
|
|
|
|
|
|
(cherry picked from commit 5371dccbe9745f74cdc1865d0f0eea26867ee89c)
|
|
|
|
|
|
|
|
|
|
(cherry picked from commit e6c189a2d86e516fda84700c90056cb0da6d66e3)
|
|
(cherry picked from commit 6d3afbc196cacdc9d09c7e148dbe3aecf7473611)
|
|
Probably faster to search for the link rather than a full-text search, and it
works in any language.
(cherry picked from commit 46fef6bc16de0782e9ba6dc1b6242057364c4264)
|
|
(cherry picked from commit 4329328b2772e95952d6eefdaaee5784a36ddd98)
|
|
Windows only has a "python" executable there, not "python3".
(cherry picked from commit 793961350e28434c8253ed9ddc83e756ea822dbf)
|
|
(cherry picked from commit 0fc49e8f651a933dbcf7d29bcdd783a02c8699e3)
|
|
This removes some isinstance asserts which are outdated. Mypy should be able to
alert us in those cases anyways.
(cherry picked from commit 3f8b9520c2c27d9efb484278925315bb9a0f029f)
|
|
This reverts commit c7b0023dcd576f7e7d6223f94a4ced5f2932afc5.
There's a new pytest-rerunfailures version out now.
(cherry picked from commit b2f48b5839efbf33cb4896067ce6a934faabd8f0)
|
|
(cherry picked from commit 831d696de2a7a3c259d2025178b5372b2c9e9c61)
|
|
See https://github.com/HypothesisWorks/hypothesis/issues/2370
(cherry picked from commit f33e15aaca0d8df77f93ffe5d09a621379e995c9)
|
|
(cherry picked from commit 807931fbf229f2a2e1bfcad0df301a80fae5d005)
|
|
(cherry picked from commit e3f527b69753737d5bfd7de30b2f7bd42e13b8d8)
|
|
(cherry picked from commit 73eb3f5d6a761a16bd353c5e789a211566e90417)
|
|
|
|
|
|
Different to #4415, this only changes the color for the command mode, which
means private mode is still clearly distinguishable in normal mode.
See #3981
(cherry picked from commit c8cfeaa59c9f059a8677f175c0eaa61422c90a03)
|
|
Thanks to snoopy-coder for the report and initial patch!
See #5186
(cherry picked from commit 3b836312e72fc9b72d380357768e8dead24ad220)
|
|
Real fix in master:
31a3aa584aa2dd1ceff4a58b4c88ebe5146e22df
|
|
QtWebEngine upgrades seem to have issues with old service workers around. As a
workaround, let's delete the Service Worker directory (keeping one backup
around) when the Qt version changes (and also once on Qt 5.14 to get rid of
existing bad data).
Related Qt issues:
- https://bugreports.qt.io/browse/QTBUG-72532
- https://bugreports.qt.io/browse/QTBUG-82105
It seems to be okay to delete those, as the website can re-register them, and
they don't seem to have any persistent data storage. Relevant reading:
- https://github.com/chromium/chromium/blob/master/content/browser/service_worker/README.md
- https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API
- https://w3c.github.io/ServiceWorker/
- https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage
Fixes #4853
(cherry picked from commit 84541de04b06f3d40d11fb38669367b0905f04a0)
|
|
When initially reading a config.py and trying to validate QtFont values,
Font.default_size is still set to None. This is because it needs to be
initialized later in _late_init, as doing so requires a QApplication.
This results in the following error while running config.py:
Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/qutebrowser/config/configfiles.py", line 731, in read_config_py
exec(code, module.__dict__)
File ".../.config/qutebrowser/config.py", line 52, in <module>
c.fonts.debug_console = 'default_size default_family'
File "/usr/lib/python3.8/site-packages/qutebrowser/config/config.py", line 611, in __setattr__
self._config.set_obj(name, value, pattern=self._pattern)
File "/usr/lib/python3.8/site-packages/qutebrowser/config/config.py", line 457, in set_obj
self._set_value(opt, value, pattern=pattern,
File "/usr/lib/python3.8/site-packages/qutebrowser/config/config.py", line 317, in _set_value
opt.typ.to_py(value) # for validation
File "/usr/lib/python3.8/site-packages/qutebrowser/config/configtypes.py", line 1336, in to_py
if size.lower().endswith('pt'):
AttributeError: 'NoneType' object has no attribute 'lower'
Similarly to what's done for configtypes.Font, assume that a None size is fine.
Note that the default_size setting already gets validated via a separate regex
anyways.
Our tests didn't catch this because the init_patch patching already set
default_size to a non-None value. While this makes sense for the rest of the
tests, in test_configinit we really should have the real default value.
Fixes #5223
(cherry picked from commit d68f484b6d003e5708fe390a921175c6c7777641)
|
|
This way, we get the proper traceback on stdout (even with the default
loglevel), and not the resulting exception traceback we're not very interested
in.
See #5223
(cherry picked from commit 14076540ff29952e3805496e755657557b4c8f59)
|
|
(cherry picked from commit 68f8592abf658ec3882e9ad674281f0e23304cff)
|
|
In savemanager.py, we used self._args to call handle_fatal_exc(), but that
attribute doesn't actually exist. This was a regression introduced in
b11f571e23c15293ed0a5dad6fe3194b20421ba0.
This commit is a more conservative version of
15801a89ab37f1252c9d9377698dbd6a1a4c6ec5.
|
|
|
|
|
|
|
|
|
|
Fixes #5202
|
|
|
|
We need a space there so that QtWebEngine parses the header properly.
|
|
Fixes #5214
|
|
Fixes #5210
See #4445
|
|
[requires.io] dependency update on master branch
|
|
|
|
|
|
|
