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.
The IRC relay protocol's PASS handler compared the server password with
the client-supplied value using strcmp, leaking the password byte-by-byte
via response timing. This is the same class of bug fixed for the api and
weechat protocols, on a separate code path that did not go through
relay_auth_check_password_plain.
Extract the HMAC-then-constant-time-compare logic from
relay_auth_check_password_plain into relay_auth_password_equals, then
use it in both the plain-auth wrapper and the IRC PASS handler.
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>
1: error: Failure in TEST(RelayApiMsg, HotlistToJson)
1: expected <2024-05-26T10:29:37.716512Z>
1: but was <2024-05-26T10:29:37.000000Z>
1: difference starts at position 20 at: <T10:29:37.000000Z >
New fields returned:
- "input" (string): content of input
- "input_position" (integer): position in input (starts at 0)
- "input_multiline" (boolean): true if the buffer allows multiline input
This parameter is the number of lines to return for buffers with free content.
Its default value is `0` if "lines" is set to `0`, otherwise all buffer lines
are returned.
Sébastien Helleu