EIP-712 typehash is incorrect for several functions in `MetaTxLib`

[code423n4]

Lines of code

https://github.com/code-423n4/2023-07-lens/blob/main/contracts/libraries/constants/Typehash.sol#L33 https://github.com/code-423n4/2023-07-lens/blob/main/contracts/libraries/constants/Typehash.sol#L23 https://github.com/code-423n4/2023-07-lens/blob/main/contracts/libraries/constants/Typehash.sol#L25 https://github.com/code-423n4/2023-07-lens/blob/main/contracts/libraries/constants/Typehash.sol#L15 https://github.com/code-423n4/2023-07-lens/blob/main/contracts/libraries/constants/Typehash.sol#L21

Vulnerability details

Bug Description

In LensHub.sol, the second parameter of setProfileMetadataURIWithSig() is declared as metadataURI:

LensHub.sol#L119-L123

    function setProfileMetadataURIWithSig(
        uint256 profileId,
        string calldata metadataURI,
        Types.EIP712Signature calldata signature
    ) external override whenNotPaused onlyProfileOwnerOrDelegatedExecutor(signature.signer, profileId) {

However, its EIP-712 typehash stores the parameter as metadata instead:

Typehash.sol#L33

bytes32 constant SET_PROFILE_METADATA_URI = keccak256('SetProfileMetadataURI(uint256 profileId,string metadata,uint256 nonce,uint256 deadline)');

---

The PostParams struct (which is used for postWithSig()) has address[] actionModules and bytes[] actionModulesInitDatas as its third and fourth fields:

Types.sol#L178-L185

    struct PostParams {
        uint256 profileId;
        string contentURI;
        address[] actionModules;
        bytes[] actionModulesInitDatas;
        address referenceModule;
        bytes referenceModuleInitData;
    }

However, the third and fourth fields in its typehash are declared as address collectModule and bytes collectModuleInitData instead:

Typehash.sol#L23

bytes32 constant POST = keccak256('Post(uint256 profileId,string contentURI,address collectModule,bytes collectModuleInitData,address referenceModule,bytes referenceModuleInitData,uint256 nonce,uint256 deadline)');

This occurs for the commentWithSig() and quoteWithSig() functions as well:

Typehash.sol#L25

bytes32 constant QUOTE = keccak256('Quote(uint256 profileId,string contentURI,uint256 pointedProfileId,uint256 pointedPubId,uint256[] referrerProfileIds,uint256[] referrerPubIds,bytes referenceModuleData,address collectModule,bytes collectModuleInitData,address referenceModule,bytes referenceModuleInitData,uint256 nonce,uint256 deadline)');

Typehash.sol#L15

bytes32 constant COMMENT = keccak256('Comment(uint256 profileId,string contentURI,uint256 pointedProfileId,uint256 pointedPubId,uint256[] referrerProfileIds,uint256[] referrerPubIds,bytes referenceModuleData,address collectModule,bytes collectModuleInitData,address referenceModule,bytes referenceModuleInitData,uint256 nonce,uint256 deadline)');

---

The fourth and fifth fields in the MirrorParams struct (which is used for mirrorWithSig()) are declared as referrerProfileIds and referrerPubIds:

Types.sol#L282-L289

    struct MirrorParams {
        uint256 profileId;
        uint256 pointedProfileId;
        uint256 pointedPubId;
        uint256[] referrerProfileIds;
        uint256[] referrerPubIds;
        bytes referenceModuleData;
    }

However, its EIP-712 typehash declares these fields as referrerProfileId and referrerPubId instead:

Typehash.sol#L21

bytes32 constant MIRROR = keccak256('Mirror(uint256 profileId,uint256 pointedProfileId,uint256 pointedPubId,uint256[] referrerProfileId,uint256[] referrerPubId,bytes referenceModuleData,uint256 nonce,uint256 deadline)');

Impact

Due to the use of incorrect typehashes, the signature verification in the functions listed above is not EIP-712 compliant.

Contracts or dapps/backends that use "correct" typehashes that match the parameters of these functions will end up generating different signatures, causing them to revert when called.

Recommended Mitigation

Amend the typehashes shown above to have matching parameters with their respective functions.

Assessed type

Error

[donosonaumczuk]

We accept it but we consider it Low severity instead. "assets are not at risk, function incorrect as to spec".

[c4-sponsor]

donosonaumczuk marked the issue as disagree with severity

[c4-judge]

Picodes marked the issue as primary issue

[c4-judge]

Picodes marked the issue as satisfactory

[Picodes]

Keeping this under Medium severity as this breaks the EIP712 compliance, so can be seen as an instance of "function of the protocol or its availability could be impacted"

[c4-judge]

Picodes marked the issue as selected for report