You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to a nil dereference, a malicious operator can bring down an aggregator by nil dereference when verifying the bls key.
Inside SendSignedTaskResponseToAggregator(), a call is made to the aggregator.
The payload that is provided is from the following type:
type SignedTaskResponse struct {
BatchMerkleRoot [32]byte
SenderAddress [20]byte
BatchIdentifierHash [32]byte
BlsSignature bls.Signature
OperatorId eigentypes.OperatorId
}
If we take a look further inside bls.Signature:
type Signature struct {
*G1Point `json:"g1_point"`
}
We see that it is a pointer to G1Point.
This opens up the ability of any operator to force the receiving aggregator to panic.
Please follow along with the Proof of Concept below, which will demonstrate the panic on a running localnet.
Given we don't control the signature type and forking would be overkill, the fix consists in adding a nil-check.
The text was updated successfully, but these errors were encountered:
From cantina#32. Transcript:
Given we don't control the signature type and forking would be overkill, the fix consists in adding a
nil
-check.The text was updated successfully, but these errors were encountered: