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

test OOM by slow read attack #618

Draft
wants to merge 7 commits into
base: master
Choose a base branch
from
Draft

Conversation

kingluo
Copy link
Contributor

@kingluo kingluo commented Apr 25, 2024

part of #612

CVE-2019-9511 “Data Dribble”
CVE-2019-9517 “Internal Data Buffering”

Both attacks accumulate big responses from the backend which causes OOM.

The strange thing is, keepalive_timeout does not help, it does not reset or fin the TCP connection. For example, in “Internal Data Buffering”, the keepalive timer only stops the TCP retransmits from tempesta but does not reset the connection. I need to look into this more.

@kingluo
Copy link
Contributor Author

kingluo commented Apr 26, 2024

There are two workarounds for this issue:

  1. keepalive_timeout will send a FIN, so the downstream connection will be closed after the timeout, and the large response body received from the upstream will be discarded, so OOM is avoided.

  2. set http_body_len frang limit.

But IMO, the perfect solution may be to support buffering: tempesta-tech/tempesta#498

I think it also fixes #1715.

@kingluo kingluo marked this pull request as ready for review May 6, 2024 13:12
t_stress/test_slow_read.py Outdated Show resolved Hide resolved
t_stress/test_slow_read.py Outdated Show resolved Hide resolved
}

frang_limits {
http_body_len 1000000;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not use http_body_len here. This directive does not affect the slowread attack

Copy link
Contributor Author

@kingluo kingluo May 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, as said, it's one of the workarounds of slow-read attacks. Please see my description in my comment below.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you set http_body_len 10**6, but attacker creates 100 streams with a body of 10**5KB. What will Tempesta's behavior be in this case? This test will not answer on my question, so I think it check nothing.

Copy link
Contributor Author

@kingluo kingluo May 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

http_body_len = 1MB < BODY_SIZE = 1024 * 1024 * 100 = 100MB, then the slow read attack will be broken at 10MB per stream.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We plan to remove http_body_len directive for responses in 498 so I think you should not use it for these tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should rely on a future PR, let alone no PR schedule for tempesta-tech/tempesta#498. This test should serve as a placeholder, at least to describe the workaround, otherwise, there is no point in keeping it as it will definitely fail under the current implementation, thus blocking CI.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kingluo in such cases please write comment like # TODO tempesta#498: remove the body length limit and add a comment to tempesta-tech/tempesta#498 to update the place.

Also if you see comment questions, especially with long discussions, please address them with comments in code. In this case please describe in a comment for the Tempesta configuration how does the workaround for the slow-read attack prevention actually works and reference the CVE

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay. I'll add the comment.

t_stress/test_slow_read.py Outdated Show resolved Hide resolved
t_stress/test_slow_read.py Outdated Show resolved Hide resolved
@kingluo kingluo force-pushed the jinhua/fix-1346-slow-read branch from bef5eab to 7e98c74 Compare May 15, 2024 12:04
@RomanBelozerov
Copy link
Contributor

@kingluo @krizhanovsky @const-t We should not use keepalive_timeout and http_body_len:

  1. http_body_len - an attacker can just request a resource with a body less then http_body_len and create a lot of streams/connections. And we cannot set a small value for this directive + it work for a response/request at the same time.
  2. I think keepalive_timeout also won't help from these attacks. The attacker can consume a lot of memory in a few seconds in a lot of connections/streams. And we cannot set a small value for keepalive_timeout, right?

I think we should wait for #498 issue or make a temporary workaround.

@kingluo kingluo linked an issue Aug 12, 2024 that may be closed by this pull request
6 tasks
@RomanBelozerov RomanBelozerov marked this pull request as draft December 20, 2024 13:28
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.

http2: tests for CVE-2019-9512/9517
3 participants