Note from Sponsor: cosmos limits that to 100, and normally we are setting reverse proxy to limit that.
The Bank modules AllBalances GRPC query endpoint doesnt have pagination limits which allows clients to request arbitrarily large result sets. An attacker could exploit this to cause significant resource consumption and DoS the blockchain nodes.
In grpc_query.go, AllBalances method accepts pagination params without validation:
An attacker can force nodes to:
Included this fuzztest in QA because I couldnt find the 100 limit implemented by Cosmos. I added this test to grpc_query_test.go to request 100,000 tokens with a 1 billion page size. Ran test with go test -v ./x/bank/keeper -run TestQueryAllBalancesWithExtremeLoad.
Add these to the imports:
It panics because the test timed out after about 10 minutes:
I also made a POC that shows significant memory growth even with a moderate number of tokens (10,000 tokens):
It outputs:
We can observe initial memory allocation of 303 MB and final memory allocation of 321 MB. A memory increase of 17 MB.
System memory increase is 12 MB. This is just for a single query with 10,000 tokens. In a production environment with multiple concurrent requests, multiple users and larger token sets, the memory usage could easily become unmanageable.
Confirm if cosmos indeed limits that to 100. If not, implement a maximum page size limit maybe like 100 items per page in the AllBalances query endpoint.
