-
Notifications
You must be signed in to change notification settings - Fork 5
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
base: master
Are you sure you want to change the base?
Conversation
There are two workarounds for this issue:
But IMO, the perfect solution may be to support buffering: tempesta-tech/tempesta#498 I think it also fixes #1715. |
} | ||
|
||
frang_limits { | ||
http_body_len 1000000; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
bef5eab
to
7e98c74
Compare
@kingluo @krizhanovsky @const-t We should not use
I think we should wait for #498 issue or make a temporary workaround. |
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.