A relay client could announce a huge websocket frame (or HTTP body via
"Content-Length") and dribble its payload, making WeeChat accumulate it
in a buffer that grew without limit, until all memory was exhausted. The
websocket frame path is reachable before authentication with the
"weechat" and "irc" protocols.
The announced websocket frame length and HTTP "Content-Length" are now
bounded by WEBSOCKET_FRAME_MAX_LENGTH and RELAY_HTTP_BODY_MAX_LENGTH: an
oversized websocket frame closes the connection, and an oversized body is
rejected.
An authenticated relay client using the permessage-deflate websocket
extension could send a small compressed frame that decompresses to an
unbounded amount of data, exhausting all memory and crashing WeeChat.
The output buffer in relay_websocket_inflate is now capped to
WEBSOCKET_INFLATE_MAX_SIZE: frames decompressing beyond this limit are
rejected and the connection is closed.
This fixes a test failure when the test changing the option is executed before
this one:
…/tests/unit/plugins/relay/api/test-relay-api-protocol.cpp:799: error: Failure in TEST(RelayApiProtocolWithClient, RecvJson)
expected <HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: Z5uTZwvwYNDm9w4HFGk26ijp/p0=
>
but was <HTTP/1.1 403 Forbidden
Content-Length: 0
>
difference starts at position 9 at: < HTTP/1.1 403 Forbid>
Sébastien Helleu