Skip to content

Latest commit

 

History

History
98 lines (73 loc) · 3.18 KB

011.md

File metadata and controls

98 lines (73 loc) · 3.18 KB

Low Tangerine Cod

Medium

protocol is not EIP-712 compatible

Summary

In readmy, protocol stated that it should follow eip, but it doesn't

Is the codebase expected to comply with any specific EIPs? We have used EIP-712 for verifying sign

Root Cause

E.x. there is no domainSeparator and in specific format which should be used in digesting:

    function _verify(
        FunctionName functionName,
        uint256 excessProfitCumulativeValue,
        uint256 nonce,
        bytes memory odosExecutionData,
        bytes memory signature
    ) private view returns (bool) {
        bytes32 digest;
        if (functionName == FunctionName.CDS_WITHDRAW) {
            digest = _hashTypedDataV4(
                keccak256(
                    abi.encode(
                        keccak256(
                            "Permit(uint256 excessProfitCumulativeValue,uint256 nonce)"
                        ),
                        excessProfitCumulativeValue,
                        nonce
                    )
                )
            );
        } else if (functionName == FunctionName.BORROW_WITHDRAW) {
            digest = _hashTypedDataV4(
                keccak256(
                    abi.encode(
                        keccak256("OdosPermit(bytes odosExecutionData)"),
                        odosExecutionData
                    )
                )
            );
        }

        address signer = ECDSA.recover(digest, signature);
        bytes32 hashedSigner = keccak256(abi.encodePacked(signer));
        if (hashedSigner == hashedAdminTwo) {
            return true;
        } else {
            return false;
        }
    }

contracts/Core_logic/CDS.sol#L878

According to eip docs:

Definition of domainSeparator

domainSeparator = hashStruct(eip712Domain)

where the type of eip712Domain is a struct named EIP712Domain with one or more of the below fields. Protocol designers only need to include the fields that make sense for their signing domain. Unused fields are left out of the struct type.

  • string name the user readable name of signing domain, i.e. the name of the DApp or the protocol.
  • string version the current major version of the signing domain. Signatures from different versions are not compatible.
  • uint256 chainId the [EIP-155][EIP-155] chain id. The user-agent should refuse signing if it does not match the currently active chain.
  • address verifyingContract the address of the contract that will verify the signature. The user-agent may do contract specific phishing prevention.
  • bytes32 salt an disambiguating salt for the protocol. This can be used as a domain separator of last resort.

Internal pre-conditions

No response

External pre-conditions

No response

Attack Path

No response

Impact

not following eip when protocol stated it follows in readme

PoC

No response

Mitigation

e.x. look how oz implements it https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/cryptography/EIP712.sol