Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update read header frame #1156

Merged
merged 2 commits into from
May 16, 2024
Merged

update read header frame #1156

merged 2 commits into from
May 16, 2024

Conversation

z8n24
Copy link
Contributor

@z8n24 z8n24 commented May 15, 2024

No description provided.

@z8n24
Copy link
Contributor Author

z8n24 commented May 15, 2024

最近爆出来的http2 协议的 CONTINUATION 帧 攻击(https://github.com/advisories/GHSA-4v7x-pqxf-cx7m)。 发现BFE 同样有. 通过循环CONTINUATION 帧 发送,可以打满CPU的情况。
附上 go官方的 issues: golang/go#65051

@iyangsj iyangsj merged commit 8d894b0 into bfenetworks:develop May 16, 2024
4 checks passed
clarinette9 pushed a commit that referenced this pull request Dec 29, 2024
Maintaining HPACK state requires that we parse and process all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, we don't allocate memory to store the excess headers but we do parse them. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send.

Set a limit on the amount of excess header frames we will process before closing a connection.

This is CVE-2023-45288 and Go issue https://go.dev/issue/65051.

Signed-off-by: Song Jian <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants