Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 711120 (CVE-2018-21035) - <dev-qt/qtwebsockets-5.15.0: WebSocket implementation accepts up to 2GB for frames and 2GB for messages (CVE-2018-21035)
Summary: <dev-qt/qtwebsockets-5.15.0: WebSocket implementation accepts up to 2GB for f...
Status: IN_PROGRESS
Alias: CVE-2018-21035
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL: https://bugreports.qt.io/browse/QTBUG...
Whiteboard: B3 [upstream cve]
Keywords:
Depends on: 734600 699716 725666 qt-5.15 726764 726766 726846 727518 728296 728298 728486 729020 kde-apps-20.04.3-stable 731976 731978 738364
Blocks:
  Show dependency tree
 
Reported: 2020-03-01 00:47 UTC by Sam James
Modified: 2020-09-21 12:22 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sam James archtester gentoo-dev Security 2020-03-01 00:47:22 UTC
"In Qt through 5.14.1, the WebSocket implementation accepts up to 2GB for frames and 2GB for messages. Smaller limits cannot be configured. This makes it easier for attackers to cause a denial of service (memory consumption)."

Possible patch: https://codereview.qt-project.org/c/qt/qtwebsockets/+/284735
Qt bug: https://bugreports.qt.io/browse/QTBUG-70693

It is not yet clear if upstream are planning to release a fixed 5.x or not due to API concerns.

[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-21035
Comment 1 Andreas Sturmlechner gentoo-dev 2020-03-19 18:37:36 UTC
Change is now upstream:

https://codereview.qt-project.org/gitweb?p=qt%2Fqtwebsockets.git;a=commit;h=ed93680f34e92ad0383aa4e610bb65689118ca93

Is it backportable to 5.14/5.15? Do we want to do that?
Comment 2 Davide Pesavento gentoo-dev 2020-03-20 14:35:56 UTC
(In reply to Andreas Sturmlechner from comment #1)
> Change is now upstream:
> 
> https://codereview.qt-project.org/gitweb?p=qt%2Fqtwebsockets.git;a=commit;
> h=ed93680f34e92ad0383aa4e610bb65689118ca93
> 
> Is it backportable to 5.14/5.15? Do we want to do that?

It is already in the 5.15 branch. Backporting to 5.14 doesn't make sense IMHO, as the patch introduces a new API that apps have to explicitly use, so backporting won't help with the CVE at all.
Comment 3 Andreas Sturmlechner gentoo-dev 2020-03-20 20:11:02 UTC
It will take some time to get this fixed then, if I had to guess I'd say we'll stabilise 5.14.2 before thinking about 5.15.x?
Comment 4 Andreas Sturmlechner gentoo-dev 2020-06-04 20:19:50 UTC
The KDE Release Service 20.04.3 stabilisation, on which this bug is going to depend (unless patching an unknown amount of stable packages) would put us at a start of stabilisation by the end of July.
Comment 5 Sam James archtester gentoo-dev Security 2020-08-21 10:03:32 UTC
(In reply to Andreas Sturmlechner from comment #4)
> The KDE Release Service 20.04.3 stabilisation, on which this bug is going to
> depend (unless patching an unknown amount of stable packages) would put us
> at a start of stabilisation by the end of July.

How are we looking now? I'm most concerned by bug 734600 and various other fixes which won't have been backported to 5.14.x.
Comment 6 Andreas Sturmlechner gentoo-dev 2020-08-21 10:04:42 UTC
See blockers.
Comment 7 Sam James archtester gentoo-dev Security 2020-08-21 10:07:37 UTC
(In reply to Andreas Sturmlechner from comment #6)
> See blockers.

* The qt-5.15 tracker has one stabilisation blocking it (texstudio) which I'm kicking off at the moment.

* bug 726846 is VirtualBox, which does need a fix, but I think the blocker bugs on it aren't new. I'll look into it.

* bug 728278 I have no idea about the importance of.

I was just wondering if you had any additional context, fine if not. I did read the bugs!
Comment 8 Andreas Sturmlechner gentoo-dev 2020-08-21 10:15:22 UTC
Well, bug 734600 isn't fixed in 5.15.0 either so stabilisation won't do anything for it. It seems to me then that waiting for 5.15.1 and stabilise that is the better option (and always more stable than .0 anyway).

Obviously all blockers need to be fixed before that can happen.
Comment 9 Chiitoo gentoo-dev 2020-08-21 10:44:35 UTC
(In reply to Andreas Sturmlechner from comment #8)
> It seems to me then that waiting for 5.15.1 and stabilise
> that is the better option (and always more stable than .0 anyway).

I feel like I agree with this.

I mean of course we could backport all those Chromium fixes, but that will be one hefty patch...

Qt upstream target for 5.15.1 is within August, but may or may not happen.
Comment 10 Sam James archtester gentoo-dev Security 2020-08-21 10:49:06 UTC
(In reply to Andreas Sturmlechner from comment #8)
> Well, bug 734600 isn't fixed in 5.15.0 either so stabilisation won't do
> anything for it. It seems to me then that waiting for 5.15.1 and stabilise
> that is the better option (and always more stable than .0 anyway).
> 

Right, but AFAIK there were other Chromium fixes in .0 anyway. But if that's the way it works with webengine (.0 is not very stable), it's of course fine.

I'm not trying to be pushy, I just can't know unless I ask. I appreciate that Qt in general is quite a big system so it's useful to check my understanding is right.

(In reply to Chiitoo from comment #9)
> I mean of course we could backport all those Chromium fixes, but that will
> be one hefty patch...
> 

Yes, it'd be havoc. No need for that.

> Qt upstream target for 5.15.1 is within August, but may or may not happen.

Thanks for the info both. :)
Comment 11 Andreas Sturmlechner gentoo-dev 2020-08-22 18:41:04 UTC
(In reply to Sam James from comment #10)
> (In reply to Andreas Sturmlechner from comment #8)
> > Well, bug 734600 isn't fixed in 5.15.0 either so stabilisation won't do
> > anything for it. It seems to me then that waiting for 5.15.1 and stabilise
> > that is the better option (and always more stable than .0 anyway).
> 
> Right, but AFAIK there were other Chromium fixes in .0 anyway. But if that's
> the way it works with webengine (.0 is not very stable), it's of course fine.
But either you are most concerned about bug 734600 or not, right? ;) It was a general comment re .0 releases, not specific to a single component. When we stabilise a version of Qt then QtWebEngine is just one part of it - we can't mix different versions. And if we give revdeps some more time to stabilise upon a new minor version that is also benefitial.

(In reply to Sam James from comment #10)
> I'm not trying to be pushy
Don't worry about it. ;)