Inconsistent order_id type in ORDER_TYPE definition and encodeOrder function for EIP-712

[c4-bot-6]

Lines of code

https://github.com/code-423n4/2024-11-ethena-labs/blob/main/contracts/ustb/UStbMinting.sol#L32-L35
https://github.com/code-423n4/2024-11-ethena-labs/blob/main/contracts/ustb/UStbMinting.sol#L442-L456

Vulnerability details

Impact

The mismatch between the order_id type (string in ORDER_TYPE and bytes32 in encodeOrder) can cause unexpected behavior during order hashing and EIP712 signature verification. This inconsistency could result in order verification failures, even if the provided signature is correct. It could prevent valid minting and redemption orders from processing, thereby impacting users who depend on this contract’s stablecoin services.

Proof of Concept

In the UStbMinting contract:

1. The ORDER_TYPE constant on UStbMinting.sol#L32 expects order_id as a string:

   bytes32 private constant ORDER_TYPE = keccak256("Order(string order_id, ...)");

2. However, in the encodeOrder function on UStbMinting.sol#L442-L456, the order_id is converted to bytes32:

   abi.encode(
       ORDER_TYPE,
       keccak256(bytes(order.order_id)), // This outputs bytes32, while ORDER_TYPE expects string
       ...
   );

3. This discrepancy can cause the generated EIP712 hash to mismatch, leading to failed signature verification.

In https://eips.ethereum.org/EIPS/eip-712#definition-of-typed-structured-data-%F0%9D%95%8A

Definition: The dynamic types are bytes and string. These are like the atomic types for the purposed of type declaration, but their treatment in encoding is different.

Recommended Mitigation Steps

 abi.encode(
       ORDER_TYPE,
--     keccak256(bytes(order.order_id))
++     keccak256(order.order_id),
       ...
   );

[c4-judge]

0xEVom marked the issue as unsatisfactory:
Invalid

[c4-judge]

0xEVom removed the grade

[c4-judge]

0xEVom changed the severity to QA (Quality Assurance)