Rigor Protocol contest - kaden's results

Community lending and instant payments for new home construction.

General Information

Platform: Code4rena

Start Date: 01/08/2022

Pot Size: $50,000 USDC

Total HM: 26

Participants: 133

Period: 5 days

Judge: Jack the Pug

Total Solo HM: 6

Id: 151

League: ETH

Rigor Protocol

Findings Distribution

Researcher Performance

Rank: 41/133

Findings: 3

Award: $157.21

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

🌟 Selected for report: 0xA5DF

Also found by: Bahurum, Lambda, bin2chen, byndooa, cryptphi, hansfriese, horsefacts, kaden, neumo, panprog, rokinot, scaraven, sseefried

Labels

bug
duplicate
3 (High Risk)
valid

Awards

94.8726 USDC - $94.87

External Links

Lines of code

https://github.com/code-423n4/2022-08-rigor/blob/5ab7ea84a1516cb726421ef690af5bc41029f88f/contracts/Project.sol#L219 https://github.com/code-423n4/2022-08-rigor/blob/5ab7ea84a1516cb726421ef690af5bc41029f88f/contracts/Project.sol#L386 https://github.com/code-423n4/2022-08-rigor/blob/5ab7ea84a1516cb726421ef690af5bc41029f88f/contracts/Community.sol#L509

Vulnerability details

Description:

Methods requiring signed data which do not require that the signature has not already been used, e.g. Project.addTasks, Project.changeOrder, and Community.escrow; are vulnerable to signature replay attacks. For example, a malicious actor may take a past transaction on one of these methods and re-execute it by passing the same _data and _signature, causing unexpected effects.

Remediation:

It's recommended to require a nonce be passed with all signed data and that a check is performed to ensure that every individual data packet can only be executed once.

#0 - parv3213

2022-08-17T06:41:08Z

Subset of #162 #161

Rebasing and fee-on-transfer tokens will break accounting logic
Severity: Low
Context:
Description:

The accounting logic used throughout the protocol assumes that the balance of tokens will not change during the lifecycle. As such, it is important that tokens used in the protocol do not contain any rebasing, fee-on-transfer, or similar balance changing logic. Failure to use static balance tokens will result in unexpected effects including locked funds and failed transactions.

Remediation

It's recommended to take care in ensuring that tokens used in the protocol do not contain rebasing, fee-on-transfer, or similar balance changing logic.

Avoid decoding unused values
Severity: Gas Optimization
Context:
Description:

In Project.raiseDispute, all values are decoded from _data, but only the first two values are used. The additional logic required to decode the last three values costs significant gas without any benefit.

Remediation:

Don't decode the final three values as they're not being used to reduce gas usage from 217449 to 216464.

Use uint256 over smaller uint types when possible
Severity: Gas Optimization
Context:
Description:

In Disputes.raiseDispute, _actionType is decoded from _data and casted to a uint8 type. This is unnecessary and inefficient as the necessary logic can be performed with a uint256, and when compiled, _actionType gets casted back to uint256 costing additional gas in the process.

Remediation:

Decode _actionType as a uint256 in Disputes.raiseDispute to reduce gas usage from 217449 to 217412.

Save storage variables locally when reused
Severity: Gas Optimization
Context:
Description:

Throughout Community.sol and Project.sol, there are storage variables which are reused within the same method. This should be generally avoided as it is much more efficient to save a variable locally and retrieve from the stack or memory instead of storage.

Remediation:
  • In Community.lendToProject, save _communities[_communityId] to a local variable to reduce gas usage from 190993 to 190425.
  • In Project.lendToProject, save builder to a local variable to reduce gas usage from 108069 to 107986
  • In Project.setComplete, save tasks[_taskId] to a local variable to reduce gas usage from 93713 to 93635
  • In Project.changeOrder, save tasks[_taskId] to a local variable to reduce gas usage from 75640 to 75459
Use optimal comparison operator
Severity: Gas Optimization
Context:
  • Throughout the contracts
Description:

Throughout the contracts, suboptimal comparison operators are used.

Remediation:

Optimal comparison operators should be used as follows:

  • When checking that uints are greater than 0, use value != 0 instead of value > 0 to save 44 gas
  • When checking that a uint is less/greater than or equal to another, use, e.g. value > otherValue - 1 instead of value >= otherValue to save 38 gas
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