Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CVE-2018-10895: Remote code execution due to CSRF on the qute://settings page #4060

Closed
The-Compiler opened this issue Jul 11, 2018 · 3 comments
Closed

CVE-2018-10895: Remote code execution due to CSRF on the qute://settings page #4060

The-Compiler opened this issue Jul 11, 2018 · 3 comments
Labels
bug: behavior Something doesn't work as intended, but doesn't crash. component: config Issues related to configuration. priority: 0 - high Issues which are currently the primary focus.

Comments

@The-Compiler
Copy link
Member

The-Compiler commented Jul 11, 2018 •
edited
Loading

Description

Due to a CSRF vulnerability affecting the qute://settings page, it was
possible for websites to modify qutebrowser settings. Via settings like
editor.command, this possibly allowed websites to execute arbitrary code.

This issue has been assigned CVE-2018-10895.

Affected versions

The issue was introduced in v1.0.0, as part of commit ffc29ee.

It was fixed in the v1.4.1 release, in commit 43e58ac.

All releases between v1.0.0 and v1.4.0 (inclusive) are affected.
Backported patches are available, but no additional releases are planned:

v1.1.x: ff686ff (patch)
v1.2.x: c3361c3 (patch)
v1.3.x: c2ff32d (patch)
v1.4.x: 22148ce (patch)
master: 43e58ac (patch)

Timeline

2018-07-09: I was made aware of the original issue privately (initially
believed by the reporter to only be a DoS issue), developed a fix and contacted
the distros Openwall mailinglist to organize a disclosure date to give
distributions time to coordinate releasing of a fix.

2018-07-10: Slightly updated patch sent to the distros mailinglist.

2018-07-11: Public disclosure.

Mitigation

Please upgrade to v1.4.1 or apply the patches above.

Note that disabling loading of autoconfig.yml is not a suitable remedy, since
settings are still applied until the next restart.

As a workaround, it's possible to patch out the vulnerable code via a
config.py file:

from qutebrowser.browser import qutescheme
qutescheme._qute_settings_set = lambda url: ('text/html', '')

While there is no known exploit for this in the wild, users are advised to
check their autoconfig.yml file (located in the config folder shown in
:version) for any unwanted modifications.

Credits

Thanks to:

  • toofar for reporting the initial issue.
  • Allan Sandfeld Jensen (carewolf) and Jüri Valdmann (juvaldma) of The Qt
    Company for their assistance with triaging and fixing the issue.
  • toofar and Jay Kamat (jgkamat) for reviewing the patch.
  • Morten Linderud (Foxboron) for suggestions on how to disclose this
    properly.
@The-Compiler The-Compiler added component: config Issues related to configuration. priority: 0 - high Issues which are currently the primary focus. bug: behavior Something doesn't work as intended, but doesn't crash. labels Jul 11, 2018
The-Compiler added a commit that referenced this issue Jul 11, 2018
@The-Compiler
CVE-2018-10895: Fix CSRF issues with qute://settings/set URL
ff686ff 
In ffc29ee (part of v1.0.0), a
qute://settings/set URL was added to change settings.

Contrary to what I apparently believed at the time, it *is* possible for
websites to access `qute://*` URLs (i.e., neither QtWebKit nor QtWebEngine
prohibit such requests, other than the usual cross-origin rules).

In other words, this means a website can e.g. have an `<img>` tag which loads a
`qute://settings/set` URL, which then sets `editor.command` to a bash script.
The result of that is arbitrary code execution.

Fixes #4060
See #2332

(cherry picked from commit 43e58ac)
The-Compiler added a commit that referenced this issue Jul 11, 2018
@The-Compiler
CVE-2018-10895: Fix CSRF issues with qute://settings/set URL
c3361c3 
In ffc29ee (part of v1.0.0), a
qute://settings/set URL was added to change settings.

Contrary to what I apparently believed at the time, it *is* possible for
websites to access `qute://*` URLs (i.e., neither QtWebKit nor QtWebEngine
prohibit such requests, other than the usual cross-origin rules).

In other words, this means a website can e.g. have an `<img>` tag which loads a
`qute://settings/set` URL, which then sets `editor.command` to a bash script.
The result of that is arbitrary code execution.

Fixes #4060
See #2332

(cherry picked from commit 43e58ac)
The-Compiler added a commit that referenced this issue Jul 11, 2018
@The-Compiler
CVE-2018-10895: Fix CSRF issues with qute://settings/set URL
c2ff32d 
In ffc29ee (part of v1.0.0), a
qute://settings/set URL was added to change settings.

Contrary to what I apparently believed at the time, it *is* possible for
websites to access `qute://*` URLs (i.e., neither QtWebKit nor QtWebEngine
prohibit such requests, other than the usual cross-origin rules).

In other words, this means a website can e.g. have an `<img>` tag which loads a
`qute://settings/set` URL, which then sets `editor.command` to a bash script.
The result of that is arbitrary code execution.

Fixes #4060
See #2332

(cherry picked from commit 43e58ac)
The-Compiler added a commit that referenced this issue Jul 11, 2018
@The-Compiler
CVE-2018-10895: Fix CSRF issues with qute://settings/set URL
22148ce 
In ffc29ee (part of v1.0.0), a
qute://settings/set URL was added to change settings.

Contrary to what I apparently believed at the time, it *is* possible for
websites to access `qute://*` URLs (i.e., neither QtWebKit nor QtWebEngine
prohibit such requests, other than the usual cross-origin rules).

In other words, this means a website can e.g. have an `<img>` tag which loads a
`qute://settings/set` URL, which then sets `editor.command` to a bash script.
The result of that is arbitrary code execution.

Fixes #4060
See #2332

(cherry picked from commit 43e58ac)
gentoo-bot pushed a commit to gentoo/gentoo that referenced this issue Jul 11, 2018
@jsbronder
www-client/qutebrowser: bump 1.4.1
64e278e 
CVE-2018-10895: Fix CSRF issue on the qute://settings page, leading to
possible arbitrary code execution. See the related GitHub issue for details.
qutebrowser/qutebrowser#4060

Removing all prior versions due to the above.

Package-Manager: Portage-2.3.40, Repoman-2.3.9
xtaran added a commit to qutebrowser/qutebrowser-debian that referenced this issue Jul 11, 2018
@xtaran
Update changelog for 1.4.1 release
c1f9a46 
Fixes CVE-2018-10895, a CSRF issue on the qute://settings page,
leading to possible arbitrary code execution. See this GitHub issue
for details: qutebrowser/qutebrowser#4060
This was referenced Jul 11, 2018
Closed
Closed
Open
@dotlambda dotlambda mentioned this issue Jul 11, 2018
Merged
9 tasks
@mschilli87
Copy link
Contributor

I filed a Gentoo bug to get this bumped ASAP.

@The-Compiler
Copy link
Member Author

@mschilli87 Those Gentoo bugs are probably not helpful, as the Gentoo maintainer is on the announce mailinglist as far as I know. In this case, the Gentoo package was already updated before you opened the bug...

@mschilli87
Copy link
Contributor

@The-Compiler yeah I just came back to edit my last comment. Somehow this slipped through a sync so I went ahead and filed it. Better safe then sorry I guess. But all is good now on my end. Sorry for the noise. 🙂

0-wiz-0 pushed a commit to NetBSD/pkgsrc-wip that referenced this issue Jul 13, 2018
@yorickhardy
qutebrowser: update to qutebrowser-1.4.1
8af8612 
Change Log
===========

v1.4.1
------

Security
~~~~~~~~

- CVE-2018-10895: Fix CSRF issue on the qute://settings page, leading to
  possible arbitrary code execution. See the related GitHub issue for details:
  qutebrowser/qutebrowser#4060

Fixed
~~~~~

- Rare crash when an error occurs in downloads.
- Newlines are now stripped from the :version pastebin URL.
- There's a new `mkvenv-pypi-old` environment in `tox.ini` which installs an
  older Qt, which is needed on Ubuntu 16.04.
- Worked around a Qt issue which redirects to a `chrome-error://` page when
  trying to use U2F.
- The `link_pyqt.py` script now works correctly with PyQt 5.11.
- The Windows installer now uninstalls the old version before installing the
  new one, fixing issues with qutebrowser not starting after installing v1.4.0
  over v1.3.3.
@The-Compiler The-Compiler mentioned this issue Jul 25, 2018
Open
@The-Compiler The-Compiler mentioned this issue May 23, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug: behavior Something doesn't work as intended, but doesn't crash. component: config Issues related to configuration. priority: 0 - high Issues which are currently the primary focus.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@The-Compiler @mschilli87