Описание
Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows unauthenticated memory exhaustion via oversized HTTP/2 frames.
'Elixir.Bandit.HTTP2.Frame':deserialize/2 in lib/bandit/http2/frame.ex checks the SETTINGS_MAX_FRAME_SIZE limit only after pattern-matching payload::binary-size(length), which requires the entire frame body to be present in memory before either the accept or reject clause can fire. A peer that announces a frame length up to the 24-bit maximum (~16 MiB) causes the server to buffer that entire body before the size guard is evaluated, regardless of the max_frame_size negotiated during the HTTP/2 handshake (default 16 KiB per RFC 9113).
An unauthenticated attacker holding many concurrent connections can force the server to buffer far more memory than the negotiated frame size limit should permit, leading to memory pressure and potential denial of service.
This issue affects bandit: from 0.3.6 before 1.11.0.
A flaw was found in bandit. An unauthenticated remote attacker can exploit a vulnerability in the HTTP/2 frame deserialization process by sending oversized HTTP/2 frames. This allows the attacker to force the server to buffer excessive amounts of memory, leading to memory exhaustion and a denial of service (DoS) condition.
Отчет
This IMPORTANT DoS vulnerability in Bandit's HTTP/2 implementation allows unauthenticated memory exhaustion by sending oversized frames. The size validation occurs after buffering, bypassing the negotiated max_frame_size setting. Impact is high availability loss through memory pressure. Affects Bandit versions 0.3.6 to before 1.11.0.
Ссылки на источники
Дополнительная информация
Статус:
7.5 High
CVSS3
Связанные уязвимости
Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows unauthenticated memory exhaustion via oversized HTTP/2 frames. 'Elixir.Bandit.HTTP2.Frame':deserialize/2 in lib/bandit/http2/frame.ex checks the SETTINGS_MAX_FRAME_SIZE limit only after pattern-matching payload::binary-size(length), which requires the entire frame body to be present in memory before either the accept or reject clause can fire. A peer that announces a frame length up to the 24-bit maximum (~16 MiB) causes the server to buffer that entire body before the size guard is evaluated, regardless of the max_frame_size negotiated during the HTTP/2 handshake (default 16 KiB per RFC 9113). An unauthenticated attacker holding many concurrent connections can force the server to buffer far more memory than the negotiated frame size limit should permit, leading to memory pressure and potential denial of service. This issue affects bandit: from 0.3.6 before 1.11.0.
Bandit HTTP/2 Frame Size Limit Bypass via Late Buffer Check Enables Memory Exhaustion
7.5 High
CVSS3