Upgrade to release 26.7.1:
- Fix WebSocket maxMessagePayloadSize being enforced against the
compressed on-the-wire frame length instead of the uncompressed
reassembled message size when permessage-compress
(deflate/bzip2/snappy/brotli) is negotiated. A small compressed
frame could inflate far beyond the configured limit and be
delivered to the application (a decompression-bomb style
denial-of-service; security advisory GHSA-hxp9-w8x3-p566, same
class as CVE-2016-10544). The limit is now re-checked at the
inflation site against the running uncompressed message size,
and the connection is failed with close code 1009 (message too
big) before delivery - for both the whole-message and streaming
receive APIs and every compression backend. Behaviour change:
a compressed message that inflates past maxMessagePayloadSize
is now rejected where it previously passed; uncompressed traffic
and the per-frame maxFramePayloadSize wire guard are unaffected
- Fix the permessage-deflate max_message_size receive cap silently
truncating an over-limit message and raising a zlib error instead
of cleanly rejecting it: the bounded decompress(..., max_length)
left the remaining input in unconsumed_tail undrained, so the
message was corrupted rather than reported. Decompression is now
bounded cumulatively across frames and raises
PayloadExceededError as soon as the uncompressed size would
exceed the cap
- Make bounded decompression backend-agnostic:
decompress_message_data() gains an optional max_output_len
argument (documented on the PerMessageCompress base class) and
every permessage-compress backend now honours it. deflate and
bzip2 stop inflating once the limit is reached (native
incremental cap); snappy and brotli, whose libraries expose no
output-length argument, inflate the frame (already bounded on
the wire by maxFramePayloadSize) and then reject - a weaker but
still clean per-frame guarantee. The WebSocket receive path
passes the remaining maxMessagePayloadSize budget so a
compressed frame no longer expands unbounded into memory before
the size check; the previous post-inflation check remains as a
backstop. Previously only deflate had any decompressed-output
cap, so a snappy/bzip2/brotli frame could inflate fully into
memory first
- Make the asyncio RawSocket receive size limit configurable, at
parity with the Twisted backend. The asyncio
WampRawSocketFactory now exposes
setProtocolOptions(maxMessagePayloadSize=...) /
resetProtocolOptions() (bounds [512, 2**24], default 16 MB), and
the configured value drives both the advertised handshake length
exponent and the enforced receive cap (rounded up to the next
power of two), matching the Twisted factory. Previously the
asyncio receive limit was hardwired to 16 MB (a dead
max_size=None branch), so an asyncio WAMP peer could not tighten
its RawSocket receive limit for DoS hardening and Crossbar's
RawSocket max_message_size had no effect on the asyncio path
Signed-off-by: Leon Anavi <leon.anavi@konsulko.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Leon Anavi