About frontrun finding.

[GHexxerBrdv]

Hey recently i have find a bug in code base where a malicious user can frontrun the function and reuse the signature and exploit governance.

See the following code:

function delegateBySig(
        address delegatee,
        uint nonce,
        uint expiry,
        uint8 v,
        bytes32 r,
        bytes32 s
    ) public {
        require(delegatee != msg.sender, "NA");
        require(delegatee != address(0), "ZA");
        
        bytes32 domainSeparator = keccak256(
            abi.encode(
                DOMAIN_TYPEHASH,
                keccak256(bytes(name)),
                keccak256(bytes(version)),
                block.chainid,
                address(this)
            )
        );
        bytes32 structHash = keccak256(
            abi.encode(DELEGATION_TYPEHASH, delegatee, nonce, expiry)
        );
        bytes32 digest = keccak256(
            abi.encodePacked("\x19\x01", domainSeparator, structHash)
        );
        address signatory = ecrecover(digest, v, r, s);
        require(
            signatory != address(0),
            "ZA"
        );
        require(
            nonce == nonces[signatory]++,
            "!NONCE"
        );
        require(
            block.timestamp <= expiry,
            "EXP"
        );
        return _delegate(signatory, delegatee);
    }
    ```
    And my report is this 
    ```
    Description: In VotingEscrow::delegateBySig function user sign transaction to delegate their voting power to delegatee by signing the transaction by passing user signature v, r and s. But the function does not include msg.sender or calling address anywhere to calculate corresponding hash.allows anyone to redirect voting power by calling delegateBySig function with the senders signature.

        bytes32 domainSeparator = keccak256(
            abi.encode(
                DOMAIN_TYPEHASH,
                keccak256(bytes(name)),
                keccak256(bytes(version)),
                block.chainid,
                address(this)
            )
        );
        bytes32 structHash = keccak256(
            abi.encode(DELEGATION_TYPEHASH, delegatee, nonce, expiry)
        );
        bytes32 digest = keccak256(
            abi.encodePacked("\x19\x01", domainSeparator, structHash)
        );
This will opens a door to malicious actor to steal voting power by passing intended delegatee by intercept a pending transaction’s signature in mempool.

Impact:
High :- Redirecting voting power can significantly affect governance, mostly if the signatory controls huge amount of tokens. This could influence protocol decisions, reward allocations, or upgrades.
Likelyhood :- it can be exploit mostly (High).

Recommended Mitigation: Use calling address to calculate the corresponding hash to prevent frontrunning.

        ...

      address signatory = ecrecover(digest, v, r, s);
+     require(msg.sender == signatory, "Unauthorized caller");

        ...
Or calculate hash containing msg.sender to make sure the caller is signatory.

Proof of Concept
Proof of Concept:

Anshuman signed the transaction to delegate his voting power which contain huge impect on governance to Madhav.
Anshuman called delegateBySig function and passed his v, rand s with unique nonce.
Gaurang intercept this transaction in mempool.
Gaurang reuse the Anshuman's signature and nonce and set delegatee to his another account address. (Anshuman's transaction is pending so that the nonce will be same)
Gaurang send this transaction with higher gas fees then Anshuman's transaction making sure that his transaction will execute first.
Finally Gaurang gain voting power of Anshuman.

    ```
    
    But they invalidated it by commenting that 
    ```
    delegatee is part of the hash/digest
    ```
    But why i think this is valid high. What do you think about it?
Can you help me with this weather i am wrong or right.

[EngrPips]

It seems valid, report it, and wait for the judge's verdict.

[EngrPips]

What was the judge's comment when he invalidated this finding?

[EngrPips]

I am unsure what you mean, but then you move on to some other codebase where you can report your findings.

I have participated in contest where this stuff has invalidated. What can i do, it is downgrading me.

Didn't the judge provide any reason for invalidating it?

[GHexxerBrdv]

delegatee is part of the hash/digest
This was the comment

[GHexxerBrdv]

but here delegate is the address to whom we are delegating our vote.
and there is not signer verification weather the signature of the caller or not. any one can reuse the signature.

[GHexxerBrdv]

Didn't the judge provide any reason for invalidating it?

no the only comment was there

[GHexxerBrdv]

Bro can you help me with this two issue? i am becoming under confidante now. i need your help.

[EngrPips]

Any time, Friend.

[GHexxerBrdv]

Hey i have just asked the protocol memebr about invalidating the finding. They told me this

The ecrecover operation uses the digest, which includes the structHash and the structHash itself includes the delegatee address. The user (signatory) signs the digest and provides the v,r,s values. If a malicious user tries to use these v,r,s values and pass in a different malicious delegatee, the signature verification fails as the honest user never signed the digest for another delegatee. 

FYI the user was never expected to call delegateBySig, this is something relayers use to perform gasless txs. In this case, they use the v,r,s values provided by the user and pass in the delegatee the user signed the digest for.

And According to them the user will sign the digest which include delegatee. And attacker can not reuse this .
What is your thought in this?

[GHexxerBrdv]

I think i should ask this on discord also, so that i can get multiple thoughts on this.

[EngrPips]

Yeah, in Discord, you have more people to respond. I see Equious helps you resolve the issue. Keep crushing it.

[GHexxerBrdv]

yeah thanks buddy