-
Notifications
You must be signed in to change notification settings - Fork 285
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
fix(security): close DDoS vulnerability in eth tx consistenty strategy #2001
Comments
Can we fix it by having a specified time delay in-between requests instead of limiting the range? |
@jagpreetsinghsasan A rate-limiter would be a partial solution because it can be defeated. For example if it rate limits based on IP address then one can use a set of proxies to avoid it entirely. With that said, everything else is also just a partial solution because nothing eliminate the possibility of DoS completely. It is a cat and mouse game that has to be played forever. Layering defenses is almost always a good idea, so IMO the strongest protection would be to do both. |
Thanks @petermetz for descriptive reasoning. And I agree 100% with the fact that, layering the security measures is the best way out. |
Hello @petermetz Can you assign me on this one? Thanks |
@aldousalvarez Done, than kyou! |
@aldousalvarez My bad, |
Fixes hyperledger-cacti#2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Fixes hyperledger-cacti#2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Fixes hyperledger-cacti#2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Fixes hyperledger-cacti#2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Fixes hyperledger-cacti#2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Fixes hyperledger-cacti#2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Fixes hyperledger-cacti#2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Fixes hyperledger-cacti#2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Fixes hyperledger-cacti#2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Fixes hyperledger-cacti#2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Fixes hyperledger-cacti#2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Fixes hyperledger-cacti#2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Fixes hyperledger-cacti#2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Fixes hyperledger-cacti#2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Fixes hyperledger-cacti#2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Fixes #2001 Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
Description
The application performs some repetitive tasks in a loop and defines the number of times to perform the loop according to user input. A very high value could cause the application to get stuck in the loop and to be unable to continue to other operations.
Affected files are all the eth flavored connector plugins that have the
consistencyStrategy
request parameter when executing transactions.packages/cactus-plugin-ledger-connector-besu/src/main/typescript/plugin-ledger-connector-besu.ts
packages/cactus-plugin-ledger-connector-xdai/src/main/typescript/plugin-ledger-connector-xdai.ts
packages/cactus-plugin-ledger-connector-quorum/src/main/typescript/plugin-ledger-connector-quorum.ts
Impact
An attacker could input a very high value, potentially causing a denial of service (DoS).
Remediation Recommendation
Don't base a loop on loosely validated user-provided data. The range should be limited. Always include a maximum value for each user input in the openapi.json specs.
Change the maximum for allowed block count to 20 thousand (a little over what the ethereum main net confirms in a 72 hour period according to the latest statistics at time of this writing: https://ycharts.com/indicators/ethereum_blocks_per_day
Breaking Change Discussion
Fixing this will be a breaking change, because previously valid requests will now get rejected by the API server.
An argument could be made that it's only a breaking change for those who were previously sending malicious requests and for no one else and therefore it is not really a breaking change even though it technically is.
@izuru0 @takeutak @jagpreetsinghsasan Please weigh in on the question presented in
Breaking Change Discussion
The text was updated successfully, but these errors were encountered: