-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Comments
I looked at some other browsers, and almost all browsers using QtWebEngine have a similar issue (if they allow overriding certificate errors): QtWebEngine
WebKitGTK
QtWebKit
Others
|
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
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
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
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)
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)
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)
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)
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)
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)
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)
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)
Fixes:
|
I requested a CVE via GitHub. Waiting for the assignment before doing a release - hoping for Monday or Tuesday. |
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. |
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? |
@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. |
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. |
GitHub now has assigned CVE-2020-11054 to this issue. I plan to release v1.11.1 tomorrow. |
v1.11.1 is now released, and a security advisory published. |
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: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
):However, when reloading the page (or loading it again in another tab), the URL is green:
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 text was updated successfully, but these errors were encountered: