code423n4 commented 1 year ago

Lines of code

https://github.com/code-423n4/2023-07-lens/blob/cdef6ebc6266c44c7068bc1c4c04e12bf0d67ead/contracts/LensHub.sol#L109 https://github.com/code-423n4/2023-07-lens/blob/cdef6ebc6266c44c7068bc1c4c04e12bf0d67ead/contracts/LensHub.sol#L200

Vulnerability details

Impact

A potential Denial of Service (DoS) vulnerability has been identified in LensHub.sol's setProfileImageURIWithSig and setProfileMetadataURIWithSig methods. An attacker, or 'griefer', could potentially exploit this vulnerability to interfere with a user's attempt to update their profile image by front-running the transaction and modifying the profile metadata instead.

LensHub.sol's current implementation has a security gap where both setProfileImageURIWithSig and setProfileMetadataURIWithSig functions share the same input parameters and signature verification. As a result, these two functions can be exploited by a malicious entity.

For example, consider the following implementation of setProfileImageURIWithSig:

    /// @inheritdoc ILensProtocol
    function setProfileImageURIWithSig(
        uint256 profileId,
        string calldata imageURI,
        Types.EIP712Signature calldata signature
    ) external override whenNotPaused onlyProfileOwnerOrDelegatedExecutor(signature.signer, profileId) {
        MetaTxLib.validateSetProfileImageURISignature(signature, profileId, imageURI);
        ProfileLib.setProfileImageURI(profileId, imageURI);
    }

It has a counterpart, setProfileMetadataURIWithSig, which looks like this:

    function setProfileMetadataURIWithSig(
        uint256 profileId,
        string calldata metadataURI,
        Types.EIP712Signature calldata signature
    ) external override whenNotPaused onlyProfileOwnerOrDelegatedExecutor(signature.signer, profileId) {
        MetaTxLib.validateSetProfileMetadataURISignature(signature, profileId, metadataURI);
        ProfileLib.setProfileMetadataURI(profileId, metadataURI);
    }

The issue arises when a user attempts to update their profile image. A malicious actor could monitor the mempool for the user's transaction, copy the data, and then front-run the user's transaction by calling the setProfileMetadataURIWithSig function using the copied data. This would result in the user's profile metadata being updated instead of the intended profile image.

Moreover, the attacker's front-running transaction would also consume the victim's nonce and signature, thereby invalidating the victim's transaction and potentially causing it to fail due to the nonce mismatch, leading to a waste of gas and possible DoS.