Platform: Code4rena
Start Date: 16/02/2023
Pot Size: $144,750 USDC
Total HM: 17
Participants: 154
Period: 19 days
Judge: Trust
Total Solo HM: 5
Id: 216
League: ETH
Rank: 17/154
Findings: 2
Award: $2,089.29
🌟 Selected for report: 0
🚀 Solo Findings: 0
2028.0263 USDC - $2,028.03
The half-life defined by MINUTE_DECAY_FACTOR can be extended from 12h up to 24h.
minutesPassed is truncated to the minute. This means that the actual time passed may be up to a minute more than calculated. _updateLastFeeOpTime is used to only allow updates when at least one minute has passed. This indeed prevents a complete griefing halt of the decay, but still allows for almost one minute extra to be taken from each update (at most one per minute), thus enabling the decay to be slowed down to almost half.
Do not mix minutes and seconds in the same reference. For example, let lastFeeOperationTime itself be the nearest lesser whole minute, and update (as is currently done) based on whole minutes as well. This automatically also prevents a complete griefing.
#0 - c4-judge
2023-03-08T10:52:01Z
trust1995 marked the issue as satisfactory
#1 - c4-judge
2023-03-08T10:52:06Z
trust1995 marked the issue as primary issue
#2 - tess3rac7
2023-03-13T23:08:12Z
If I'm not mistaken, this attack requires a malicious user to successfully force a fee-op-eligible transaction (borrowing/redeeming) to be mined exactly 59 seconds after a minute mark 43,200 times in a row. Whilst theoretically possible, it is very resource intensive, and almost impossible to guarantee 40,000+ transactions to be mined at the exact desired timestamps in a row. I don't think this is a practical possibility.
#3 - c4-sponsor
2023-03-13T23:08:18Z
tess3rac7 marked the issue as sponsor disputed
#4 - trust1995
2023-03-20T09:15:11Z
@tess3rac7 Can you please clarify why "exactly 59 seconds" is required?
#5 - tess3rac7
2023-03-20T14:56:52Z
As per my understanding of the report, it's claiming that due to floor division error when converting seconds -> minutes, 1min59s passed would theoretically have the same effect as 1min passed. Anything less than 59 seconds wouldn't satisfy the warden's claim of almost doubling the half life. And anything over would roll over into the next minute, nullifying the bug.
#6 - trust1995
2023-03-20T15:09:01Z
They are saying it can be extended up to 2x. I think the described behavior is incorrect, up to med severity.
#7 - c4-judge
2023-03-20T15:09:42Z
trust1995 marked issue #33 as primary and marked this issue as a duplicate of 33
#8 - d3e4
2023-03-23T09:34:18Z
@tess3rac7 There are 720 minutes in 12 h. Worst case is when updated every 119 seconds 720 times in a row. Then 60 s * 720 = 12 h will have been counted, but 119 s * 720 = 23 h 48 m will actually have passed. But this issue doesn't require an attacker; 0-59 s is skimmed off at every update, with an expectation of 29.5 s for infrequent updates. So the expected additional half-life is 29.5 s times the number of updates per 12 h, if that number is sufficiently low. If there is an update every block, let's say every 13 s, then 0-12 s will be skimmed off every minute for an average of 6 s, so the 12 h decay will be delayed by 6 s * 720 = 72 min.