#38920 [BC-Medium] teku remote DoS
Submitted on Jan 18th 2025 at 00:07:35 UTC by @gln for Attackathon | Ethereum Protocol
Report ID: #38920
Report Type: Blockchain/DLT
Report severity: Medium
Target: https://github.com/Consensys/teku
Impacts:
Increasing greater than or equal to 25% of network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours
Description
Brief/Intro
Teku does not validate parameters of incoming BlobSidecarsByRange requests.
Malformed BlobSidecarsByRange request allows an attacker to bypass validateRequest() method and also approveObjectsCount() (internal rate limiter).
Vulnerability Details
Let's look at the code which process req/resp requests https://github.com/Consensys/teku/blob/master/networking/eth2/src/main/java/tech/pegasys/teku/networking/eth2/rpc/core/Eth2IncomingRequestHandler.java#L100
Corresponding validateRequest() method is called to verify the request
If validateRequest() do not return error, actual message handler is called
Let's look at BlobSidecarsByRange handler https://github.com/Consensys/teku/blob/master/networking/eth2/src/main/java/tech/pegasys/teku/networking/eth2/rpc/beaconchain/methods/BlobSidecarsByRangeMessageHandler.java#L85
To verify request parameters calculateRequestedCount is called
Basically message.getCount() returns uint64, the type of return value is long, if message.getCount() is large enough, integer overflow will occur and result will be negative
This check will pass if requestedCount is negative
Thus validateRequest() checks can be bypassed.
Let's look at BlobSidecarsByRange handler, there are few more checks https://github.com/Consensys/teku/blob/master/networking/eth2/src/main/java/tech/pegasys/teku/networking/eth2/rpc/beaconchain/methods/BlobSidecarsByRangeMessageHandler.java#L110
Assuming message is malformed, so calculateRequestedCount() will return negative value
We need to look at approveBlobSidecarsRequest() method https://github.com/Consensys/teku/blob/master/networking/eth2/src/main/java/tech/pegasys/teku/networking/eth2/peers/DefaultEth2Peer.java#L386
The approveObjectsRequest() method will finally call this method https://github.com/Consensys/teku/blob/master/networking/eth2/src/main/java/tech/pegasys/teku/networking/eth2/peers/RateTrackerImpl.java#L48
if objectsWithinWindow is negative, this check will not pass
here objectsWithinWindow can be made negative (if objectCount is negative)
As a result, negative objectsCount allows us to bypass internal rate limiter and request as many blobs as there are available.
Impact Details
Maximum amount of space occupied by blobs is around 50GB https://lighthouse-book.sigmaprime.io/advanced-blobs.html
This is a potential Denial of Service issue, as an attacker could request huge amount of blobs from a teku node.
Link to Proof of Concept
https://gist.github.com/gln7/1b92502a6a24b8af4dab151c7f0b6827
Proof of Concept
Proof of Concept
To reproduce issue we need to patch corresponding test and verify that validateRequest() checks can by bypassed.
How to reproduce:
get teku source
apply poc.patch
run test:
You should see output like this:
when trying to request 1000 blob sidecars, validateRequest() will return error
when trying to request uint64.MAX_VALUE-1000000 sidecars, valideRequest() check will pass and sendBlobSidecars() will be called
Was this helpful?