History page parses and renders html tags

[BenjaminBrandtner]

While visiting this page which has an html input element as it's title (<input type="file">), I noticed that it got parsed like HTML and actually displays the rendered element in the qute://history/ page, whereas expected/desired behavoir would be the website title being displayed in plain text.

I then searched a bunch of unclosed html tags in google, a <b> and an <h1>. The 3 topmost items in this screenshot show that it all gets evaluated:

Version Information:
http://paste.the-compiler.org/view/61009fa1

[The-Compiler]

Whoops... 😊 That also means it's possible for pages to do XSS via the page title when an user visits the history page, which presumably at least allows them to read the user's browsing history.

cc @imransobir

[The-Compiler]

After taking a closer look, I think it's not possible to inject <script> tags - or rather, they don't get executed (because the element is created dynamically via JavaScript).

[The-Compiler]

Welp, it is actually possible - see the "security considerations" for innerHTML.

[The-Compiler]

I requested a CVE for this issue, see https://pending-requests-v5.distributedweaknessfiling.org/

[The-Compiler]

Here's a copy of the announcement I sent out:

---

Hey,

I've just released qutebrowser v1.3.3, which fixes an XSS vulnerability
on the qute://history page (:history).

The vulnerability allowed websites to inject HTML into the page via a
crafted title tag. This could allow them to steal your browsing history.

If you're currently unable to upgrade, avoid using :history.

A CVE request for this issue is pending, I'll send out another mail once
there's a CVE ID assigned.

The issue was introduced in March 2017 and part of the v0.11.0 release:
845f21b
1179ee7

The patch applies cleanly to v1.2.x and v1.1.x (but I do not plan to do
any updated releases of those):
https://github.com/qutebrowser/qutebrowser/commit/5a7869f2feaa346853d2a85413d6527c87ef0d9f.patch

It does not apply to v1.0.x and v0.11.x. If you need a backport,
please let me know, but especially on v0.11.x you'll probably have a lot
of other security issues due to an outdated QtWebKit anyways.

I plan to release v1.4.0 later this week (once PyQt 5.11 is out), but
since the bug was opened publicly, I decided to do an immediate bugfix
release. As a reminder, for security-relevant bugs, please contact me
directly at mail at qutebrowser.org.

Other bugfixes in this release:

• Crash in a workaround for a Qt 5.11 bug in rare circumstances.
• Workaround for a Qt bug which preserves searches between page loads.
• In v1.3.2 a dependency on the PyQt5.QtQuickWidgets module was accidentally
  introduced. Since that module isn't packaged everywhere, it's been removed
  again.

Sorry for the trouble!

Florian

[The-Compiler]

Unfortunately my fix caused a regression due to escaping URLs as well, causing the wrong URL to be loaded when clicking a link on the history page. I'm tracking this in #4012. I won't release a v1.3.4 because this is rather minor, but I plan to fix it in v1.4.0.

[BenjaminBrandtner]

I'm glad my first ever contribution to an open source project was useful and able to expose and fix a rather important bug. Here's to many more! (Contributions, not bugs) :)

[The-Compiler]

This issue has been assigned CVE-2018-1000559.

@BenjaminBrandtner Thanks again, especially for the screenshots and all which makes things easier! I'm not sure if you were aware of the security implications of this bug (and it's okay if you weren't!) - but if you were, note that there's usually a way to report security related issues to projects privately (mail@qutebrowser.org for qutebrowser). That way, there's less pressure on maintainers to fix things immediately, as things are less likely to be exploited (and it's possible to only announce the details when distributions updated their packages).