LUSDT non-compliance with the EIP-2612 standard

[code423n4]

Lines of code

https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/LUSDToken.sol#L254

Vulnerability details

Impact

• Inability to integrate LUSDT into contracts of other services where the DOMAIN_SEPARATOR is used or strict adherence to the EIP2612 standard is required.

• Various network analyzers that automatically determine the type of contracts will not be able to recognize that this is a token with a Permit function.

• Websites/exchanges/tools will not recognize that this is a token with a Permit function, and will therefore not provide users with the ability to pay less gas or use certain functionality, as they will not have access to the DOMAIN_SEPARATOR and automatically obtain the data.

Proof of Concept

The contract LUSDT.sol implement the EIP-2612 standard, but the implementation is incorrect. According to the standard described in https://eips.ethereum.org/EIPS/eip-2612 the contract should contain a function function DOMAIN_SEPARATOR() external view returns (bytes32) but in reality, the contract contains function domainSeparator() public view override returns (bytes32), which is a different function name. Therefore, we cannot say that it fully implements this standard since the mandatory DOMAIN_SEPARATOR method is missing `

Tools Used

• Manual review

  Recommended Mitigation Steps

• Correcting according to the standard

[c4-judge]

trust1995 marked the issue as satisfactory

[c4-judge]

trust1995 marked the issue as primary issue

[tess3rac7]

Agree with nonconformity however recommend low severity as per: https://docs.code4rena.com/awarding/judging-criteria/severity-categorization "function incorrect to spec"

[c4-sponsor]

tess3rac7 marked the issue as disagree with severity

[trust1995]

"function incorrect to spec" relates to project-defined specs, rather than breaking spec of EIPs, AFAIK. From experience with many past contests, this is in line with Medium severity due to risks of composability with additional protocols.

[c4-sponsor]

tess3rac7 marked the issue as sponsor confirmed

[c4-judge]

trust1995 marked issue #638 as primary and marked this issue as a duplicate of 638