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.

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

Security: Reloading page with certificate errors falsely shows a green URL (CVE-2020-11054) #5403

Closed
The-Compiler opened this issue May 2, 2020 · 9 comments
Labels
priority: 0 - high Issues which are currently the primary focus.
Projects

Comments

@The-Compiler
Copy link
Member

While working on 46b4d26 I noticed that only the first load of pages with certificate errors gets a correctly colored URL.

When loading a page with the default content.ssl_strict = ask setting, there's a prompt to confirm the certificate issue:

image

When answering that with "yes", the URL is then colored yellow (colors.statusbar.url.warn.fg) rather than green (colors.statusbar.url.success_https.fg):

image

However, when reloading the page (or loading it again in another tab), the URL is green:

image

This is because QtWebEngine remembers the answer internally and we don't get a certificateErrors signal anymore - unfortunately there's also no API to check the certificate state of the current page...

I'm handling this as a low-severity security vulnerability and will request a CVE. There's no way for bad actors to exploit this and the user already did override the certificate error (so should be aware that the connection is not to be trusted), but it still lures users into a false sense of security.

A fix, release and security announcement is in progress.

@The-Compiler The-Compiler added the priority: 0 - high Issues which are currently the primary focus. label May 2, 2020
@The-Compiler The-Compiler pinned this issue May 2, 2020
@The-Compiler
Copy link
Member Author

The-Compiler commented May 2, 2020

I looked at some other browsers, and almost all browsers using QtWebEngine have a similar issue (if they allow overriding certificate errors):

QtWebEngine

WebKitGTK

  • Archlinux package for surf: Has a config.h which doesn't validate TLS at all... It was dropped from the repo today, so that's going to be an AUR comment
  • Next Browser: No indicator for HTTP/HTTPS?
  • Epiphany: Implements things correctly!
  • Others: No way to override certificate errors?

QtWebKit

  • Otter Browser: ok

Others

  • Brave: ok
  • Vivaldi: ok
  • Min: No way to override certificate errors?

The-Compiler added a commit that referenced this issue May 2, 2020
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
The-Compiler added a commit that referenced this issue May 2, 2020
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
The-Compiler added a commit that referenced this issue May 2, 2020
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
The-Compiler added a commit that referenced this issue May 2, 2020
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
The-Compiler added a commit that referenced this issue May 2, 2020
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 021ab57)
The-Compiler added a commit that referenced this issue May 2, 2020
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 45a2be3)
The-Compiler added a commit that referenced this issue May 2, 2020
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 021ab57)
The-Compiler added a commit that referenced this issue May 2, 2020
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 45a2be3)
The-Compiler added a commit that referenced this issue May 2, 2020
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 021ab57)
The-Compiler added a commit that referenced this issue May 2, 2020
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 45a2be3)
The-Compiler added a commit that referenced this issue May 2, 2020
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 021ab57)
The-Compiler added a commit that referenced this issue May 2, 2020
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 45a2be3)
The-Compiler added a commit that referenced this issue May 2, 2020
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 021ab57)
The-Compiler added a commit that referenced this issue May 2, 2020
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 45a2be3)
The-Compiler added a commit that referenced this issue May 2, 2020
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 021ab57)
The-Compiler added a commit that referenced this issue May 2, 2020
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 45a2be3)
The-Compiler added a commit that referenced this issue May 2, 2020
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 021ab57)
The-Compiler added a commit that referenced this issue May 2, 2020
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 45a2be3)
The-Compiler added a commit that referenced this issue May 2, 2020
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 021ab57)
The-Compiler added a commit that referenced this issue May 2, 2020
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 45a2be3)
@The-Compiler
Copy link
Member Author

The-Compiler commented May 2, 2020

Fixes:

@The-Compiler
Copy link
Member Author

I requested a CVE via GitHub. Waiting for the assignment before doing a release - hoping for Monday or Tuesday.

@The-Compiler The-Compiler changed the title Security: Reloading page with certificate errors shows a green URL Security: Reloading page with certificate errors falsely shows a green URL May 2, 2020
@toofar
Copy link
Member

toofar commented May 2, 2020

It looks like these certificate error ignore decisions are stored in webengine's host state delegate in AllowCert here and those decisions can be cleared if the host starts returning a good certificate by chromium in DidStartResourceResponse here. So we could get out of sync in that case. Unfortunately it doesn't seem that we have any API to query or manipulate that. It isn't used or abstracted any further in the Qt code and we are isolated from the chromium networking stuff.

@dfaure
Copy link

dfaure commented May 3, 2020

Given that this appears to be a bug in QtWebEngine (and the commits here are basically workarounds), did you email security@qt-project.org about this security bug?

@The-Compiler
Copy link
Member Author

@toofar Thanks for taking a look! Yeah, we will still show "insecure" now even after the error has been fixed server-side, but that seems much less of a problem than accidentally showing "secure".

@dfaure I wouldn't call it a bug in QtWebEngine - more the lack of an API to find out whether the current connection is secure in an obvious way. I added a comment to a related issue: [QTBUG-80860] Expose certificate chain and cipher of currently viewed URL - Qt Bug Tracker. I'll also send a mail there, but I don't think this qualifies as a Qt security issue.

@The-Compiler The-Compiler added this to Focus in Roadmap May 4, 2020
@The-Compiler
Copy link
Member Author

I requested a CVE via GitHub. Waiting for the assignment before doing a release - hoping for Monday or Tuesday.

No updates on that front so far. After writing that comment, I noticed that their page says three working days, which would be Wednesday. Given that their support team seems to be reduced to COVID19 as well and this isn't something very time-critical, I hope to hear back in the next day or two, which would mean a release tomorrow, Thursday or Friday. Will keep everyone updated via this issue if something changes about that.

@The-Compiler
Copy link
Member Author

GitHub now has assigned CVE-2020-11054 to this issue. I plan to release v1.11.1 tomorrow.

@The-Compiler The-Compiler changed the title Security: Reloading page with certificate errors falsely shows a green URL Security: Reloading page with certificate errors falsely shows a green URL (CVE-2020-11054) May 6, 2020
@The-Compiler
Copy link
Member Author

v1.11.1 is now released, and a security advisory published.

Roadmap automation moved this from Focus to Done May 7, 2020
@The-Compiler The-Compiler unpinned this issue May 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: 0 - high Issues which are currently the primary focus.
Projects
Roadmap
  
Done
Development

No branches or pull requests

3 participants