-
Type:
Bug
-
Status: Closed
-
Priority:
P1: Critical
-
Resolution: Done
-
Affects Version/s: 5.11.2, 5.12.1, 5.12.4, 5.13.0, 5.14.1, 5.15
-
Fix Version/s: 5.15.0 Beta3
-
Component/s: WebSockets
-
Labels:None
-
Platform/s:
-
Commits:ed93680f34e92ad0383aa4e610bb65689118ca93
CVE-2018-21035 : https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-21035
In the websocket protocol, a websocket message can be composed a several websocket frame that are later reassembled. The Qt websocket implementation accepts a frame of maximum 2^31-2 bytes (why -2 ?).
//qwebsocketframe_p.h const quint64 MAX_FRAME_SIZE_IN_BYTES = INT_MAX - 1; const quint64 MAX_MESSAGE_SIZE_IN_BYTES = INT_MAX - 1;
This number is really huge. An attacker could make a lots of websocket connection, and sending partial messages containing frames (or partial frame) of a huge size. It could continue until he will exhaust all the virtual memory of the process running websocket (a server or a client). This will result in a crash and will cause a denial of service.
This is really easy to achieve.
Currently a qwebsocket class user cannot do anything against this, as the only signals of the class for received data are:
void textFrameReceived(const QString &frame, bool isLastFrame); void binaryFrameReceived(const QByteArray &frame, bool isLastFrame); void textMessageReceived(const QString &message); void binaryMessageReceived(const QByteArray &message);
So signals are only emitted when a frame is fully received, therefore this attack is possible.
A possible solution would be to make the maximum frame/message size, a modifiable class parameter.
Another solution could be to add a signal to the class, void dataReceived(quint64 bytesReceived); that would be triggered, every time some data are received, this would allow to discard large frame/msgs.