Golom contest - Tadashi's results

An NFT marketplace that offers the lowest industry fee, a publicly available order-book along with analytical tools.

General Information

Platform: Code4rena

Start Date: 26/07/2022

Pot Size: $75,000 USDC

Total HM: 29

Participants: 179

Period: 6 days

Judge: LSDan

Total Solo HM: 6

Id: 148

League: ETH

Golom

Findings Distribution

Researcher Performance

Rank: 130/179

Findings: 1

Award: $35.17

🌟 Selected for report: 0

🚀 Solo Findings: 0

Typos

  • “Exeute” in L526 of VoteEscrowCore.sol
  • “succesful” in L53 of GolomTrader.sol
  • “facilating” in L54 of GolomTrader.sol
  • “usefull” in L60 of GolomTrader.sol

Return value of 0 from ecrecover not checked and can be used to bypass order validation

Details: As stated in Solidity docs, ecrecover in L176 of GolomTrader.sol may return 0 on error (e.g. passing o.v different than 26 or 27). This means that the require in L177 can be bypassed by passing an Order with o.signer equal to 0.

Impact: Low? (I am marking it as a low because I couldn’t find how to exploit this to cause a high-impact attack to the contract or its users. Nevertheless, there could be a possibility that this could be combined with other potential attacks to cause high damage).

Mitigation: Add a require condition to revert the transaction in case ecrecover returns 0.

Permit signature replay across forks

Details: GolomTrader.sol defines chainId at contract deployment without reconstructing it for every signature. However, as stated in the security considerations section of EIP2612, "If the DOMAIN_SEPARATOR contains the chainId and is defined at contract deployment instead of reconstructed for every signature, there is a risk of possible replay attacks between chains in the event of a future chain split.” ****

Impact: Low (depends on the hard forking of a well-established blockchain)

Mitigation: Consider caching the chainId as is done in OpenZeppelin contracts.

Comment does not match operation

Details: The comment in L16 of TokenUriHelper.sol does not match the operation in L17:

// multiply by 4/3 rounded up
uint256 encodedLen = 4 * ((len + 2) / 3);

Indeed, consider the following counter-example: if len is equal to 3, then 4/3 of 5 is, after rounding up, 7. However, the resulting value of encodedLen is 4.

Impact: Code QA

Divide before multiply

Details: Since integer division might truncate, performing multiplication before division may avoid precision loss. Consider changing the order of multiplication and division in the following lines:****

  • L381 of GolomTrader.sol to

    uint256 protocolfee = ((o.totalAmt * amount * 50) / 10000);

Impact: Code QA

Mitigation: Perform the changes detailed above.

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