websocket: change the max_message_size default from unlimited to 32 MiB - #491
Conversation
The websocket input's `max_message_size` shipped in `v4.78.0` with a default of 0: no read limit. This could allow a websocket server to make the process allocate an unbounded amount of memory with a single streamed message, leading to an OOM kill. For existing configs the impact is limited. 32 MiB is a generous limit: typical websocket messages are orders of magnitude smaller. An explicit `max_message_size`, including 0 for unlimited, keeps its behaviour. The rare pipeline that receives larger messages fails loudly, not silently: the connection closes with a 1009 (message too big) status, an error is logged, and the input reconnects. **Ref:** * CON-545 * VM-73
|
Commits Review LGTM |
|
How did you arrive at the value of 32MiB? |
It was the value recommended by the security audit: VM-73 - F-01 - Websocket Memory Exhaustion IMO it is reasonable. 32MiB is quite large for websocket, so as a default it remains permissive while addressing the unbound memory usage issue. |
|
@Leward Yes, it does sound reasonable. Was more curious to understand how your arrived at the figure which I see was suggested by the finding which clarifies it 👌 |
2 participants
The websocket input's
max_message_sizeshipped inv4.78.0with a default of 0: no read limit. This could allow a websocket server to make the process allocate an unbounded amount of memory with a single streamed message, leading to an OOM kill.For existing configs the impact is limited. 32 MiB is a generous limit: typical websocket messages are orders of magnitude smaller. An explicit
max_message_size, including 0 for unlimited, keeps its behaviour. The rare pipeline that receives larger messages fails loudly, not silently: the connection closes with a 1009 (message too big) status, an error is logged, and the input reconnects.Ref: