reNFT - Ward's results

Collateral-free, permissionless, and highly customizable EVM NFT rentals.

General Information

Platform: Code4rena

Start Date: 08/01/2024

Pot Size: $83,600 USDC

Total HM: 23

Participants: 116

Period: 10 days

Judge: 0xean

Total Solo HM: 1

Id: 317

League: ETH

reNFT

Findings Distribution

Researcher Performance

Rank: 99/116

Findings: 2

Award: $5.79

🌟 Selected for report: 0

🚀 Solo Findings: 0

Awards

3.987 USDC - $3.99

Labels

bug
3 (High Risk)
partial-25
upgraded by judge
edited-by-warden
duplicate-418

External Links

Lines of code

https://github.com/re-nft/smart-contracts/blob/3ddd32455a849c3c6dc3c3aad7a33a6c9b44c291/src/packages/Signer.sol#L183-L193 https://github.com/re-nft/smart-contracts/blob/3ddd32455a849c3c6dc3c3aad7a33a6c9b44c291/src/packages/Signer.sol#L233-L237

Vulnerability details

Impact

The _deriveRentalOrderHash and _deriveOrderMetadataHash functions in the Signer.sol contract lack the utilization of all parameters from the structs intended for hash derivation according to the EIP-712 specifications. This omission could lead to identical hashes if it becomes possible to input the same values for all parameters except the currently excluded ones. This practice of excluding some parameters not only diminishes uniqueness and expands the potential attack surface it also introduces incompatibility with the EIP-712 specification.

Also note that unlike _deriveRentalOrderHash and _deriveOrderMetadataHash, the typeHashes of OrderMetada and RentalOrder are derived correctly, with all parameters included.

Proof of Concept

Parameters used in _deriveRentalOrderHash, rentalWallet is missing.

// Signer.sol::_deriveRentalOrderHash
keccak256(
    abi.encode(
        _RENTAL_ORDER_TYPEHASH,
        order.seaportOrderHash,
        keccak256(abi.encodePacked(itemHashes)),
        keccak256(abi.encodePacked(hookHashes)),
        order.orderType,
        order.lender,
        order.renter,
        order.startTimestamp,
        order.endTimestamp
    )
);

// RentalStructs.sol
struct RentalOrder {
    bytes32 seaportOrderHash;
    Item[] items;
    Hook[] hooks;
    OrderType orderType;
    address lender;
    address renter;
    address rentalWallet;
    uint256 startTimestamp;
    uint256 endTimestamp;
}

Parameters used in _deriveOrderMetadataHash, orderType and emittedExtraData is missing.

// Signer.sol::_deriveOrderMetadataHash
keccak256(
    abi.encode(
        _ORDER_METADATA_TYPEHASH,
        metadata.rentDuration,
        keccak256(abi.encodePacked(hookHashes))
    )
);

// RentalStructs.sol
struct OrderMetadata {
    // Type of order being created.
    OrderType orderType;
    // Duration of the rental in seconds.
    uint256 rentDuration;
    // Hooks that will act as middleware for the items in the order.
    Hook[] hooks;
    // Any extra data to be emitted upon order fulfillment.
    bytes emittedExtraData;
}

Tools Used

Manual Review

In the hash derivation functions in question, add all the parameters mentioned in the structs, taking into account the EIP-712 specification.

Assessed type

Other

#0 - c4-pre-sort

2024-01-21T17:50:14Z

141345 marked the issue as duplicate of #239

#1 - c4-judge

2024-01-28T21:04:50Z

0xean marked the issue as satisfactory

#2 - c4-judge

2024-01-30T11:16:08Z

0xean marked the issue as not a duplicate

#3 - c4-judge

2024-01-30T11:16:15Z

0xean marked the issue as duplicate of #385

#4 - c4-judge

2024-01-30T11:16:20Z

0xean marked the issue as partial-25

#5 - c4-judge

2024-01-30T14:24:44Z

0xean changed the severity to 3 (High Risk)

Awards

1.8029 USDC - $1.80

Labels

bug
2 (Med Risk)
satisfactory
duplicate-239

External Links

Lines of code

https://github.com/re-nft/smart-contracts/blob/3ddd32455a849c3c6dc3c3aad7a33a6c9b44c291/src/packages/Signer.sol#L151

Vulnerability details

Impact

The hook.extraData parameter which is being included at the hash of the hook, is a bytes type, which EIP-712 defines as dynamic. Dynamic types are encoded as the hash of the contents; and currently the extraData parameter is being encoded as-is.

That could result in unexpected integration failures with EIP712-compliant wallets or tooling that perform the encoding in the appropriate way.

Proof of Concept

https://github.com/re-nft/smart-contracts/blob/3ddd32455a849c3c6dc3c3aad7a33a6c9b44c291/src/packages/Signer.sol#L151

// Signer.sol::_deriveHookHash
    function _deriveHookHash(Hook memory hook) internal view returns (bytes32) {
        // Derive and return the hook as specified by EIP-712.
        return
            keccak256(
                abi.encode(_HOOK_TYPEHASH, hook.target, hook.itemIndex, hook.extraData)
            );
    }

Hook struct defined in RentalStructs.sol, extraData is bytes type

struct Hook {
    // The hook contract.
    address target;
    // Index of the item in the order to apply the hook to.
    uint256 itemIndex;
    // Any extra data that the hook will need.
    bytes extraData;
}

Tools Used

Manual Review

Encode the dynamic hook.extraData parameter as per the EIP-712 specification.

return keccak256(abi.encode(_HOOK_TYPEHASH, hook.target, hook.itemIndex, keccak256(hook.extraData)));

Assessed type

Other

#0 - c4-pre-sort

2024-01-21T17:50:26Z

141345 marked the issue as duplicate of #239

#1 - c4-judge

2024-01-28T21:04:59Z

0xean marked the issue as satisfactory

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter