Open c4-bot-10 opened 8 months ago
minhquanym marked the issue as sufficient quality report
This is a valid bug report. Fixed in this PR: https://github.com/taikoxyz/taiko-mono/pull/16543
dantaik (sponsor) confirmed
I don't see a direct loss of funds here and believe M is the correct severity
2 — Med: Assets not at direct risk, but the function of the protocol or its availability could be impacted, or leak value with a hypothetical attack path with stated assumptions, but external requirements.
3 — High: Assets can be stolen/lost/compromised directly (or indirectly if there is a valid attack path that does not have hand-wavy hypotheticals).
0xean changed the severity to 2 (Med Risk)
0xean marked the issue as satisfactory
0xean marked the issue as selected for report
A halted chain leads to frozen funds. The chain will progress for a minimum of 2 blocks since the calculation is correct when lastSyncedBlock =0
and when _l1BlockID-lastSyncedBlock=1
After the second block the base fee will still be correct as long as excess < issuance
for both the inflated and correct calculating since both result in excess=1
https://github.com/code-423n4/2024-03-taiko/blob/f58384f44dbf4c6535264a472322322705133b11/packages/protocol/contracts/L2/TaikoL2.sol#L279-L282
if (numL1Blocks > 0) {
uint256 issuance = numL1Blocks * _config.gasTargetPerL1Block;
excess = excess > issuance ? excess - issuance : 1;
}
At the block where the base fee is incorrect the chain is halted and funds are locked since the anchor now reverts in perpetuity.
In practice Taiko can easily release all funds by upgrading the contracts but I believe such an intervention should not be considered when evaluating the severity of an issue. From C4 Supreme Court session, Fall 2023
Contract upgradability should never be used as a severity mitigation, i.e. we assume contracts are non-upgradable.
I therefore believe a High is fair here
I don't entirely agree since the chain would be halted so soon in its existence, that being said, some amount of funds, albeit small, would likely be lost. @dantaik / @adaki2004 any last comments before this becomes H severity?
I don't entirely agree since the chain would be halted so soon in its existence, that being said, some amount of funds, albeit small, would likely be lost. @dantaik / @adaki2004 any last comments before this becomes H severity?
Agreed, can do!
My 2 cents based on what I can see -
Med
severity report, however I can't see the scenario to be direct enough or have a justifiably high probability to warrant a high severity.Agreed with @t0x1cC0de, I think this fits the description of Medium since it's more of a leak in value.
2 — Med: Assets not at direct risk, but the function of the protocol or its availability could be impacted, or leak value with a hypothetical attack path with stated assumptions, but external requirements.
awarding as H, final decision.
0xean changed the severity to 3 (High Risk)
Lines of code
https://github.com/code-423n4/2024-03-taiko/blob/f58384f44dbf4c6535264a472322322705133b11/packages/protocol/contracts/L2/TaikoL2.sol#L140-L143 https://github.com/code-423n4/2024-03-taiko/blob/f58384f44dbf4c6535264a472322322705133b11/packages/protocol/contracts/L2/TaikoL2.sol#L262-L293 https://github.com/code-423n4/2024-03-taiko/blob/f58384f44dbf4c6535264a472322322705133b11/packages/protocol/contracts/L2/TaikoL2.sol#L145-L152 https://github.com/code-423n4/2024-03-taiko/blob/f58384f44dbf4c6535264a472322322705133b11/packages/protocol/contracts/L2/TaikoL2.sol#L140-L143
Vulnerability details
Impact
The base fee calculation in the
anchor()
function is incorrect. Issuance is over inflated and will either lead to the chain halting or a severely deflated base fee.Proof of Concept
We calculate the 1559 base fee and compare it to
block.basefee
https://github.com/code-423n4/2024-03-taiko/blob/f58384f44dbf4c6535264a472322322705133b11/packages/protocol/contracts/L2/TaikoL2.sol#L140-L143But the calculation is incorrect
https://github.com/code-423n4/2024-03-taiko/blob/f58384f44dbf4c6535264a472322322705133b11/packages/protocol/contracts/L2/TaikoL2.sol#L262-L293
Instead of issuing
_config.gasTargetPerL1Block
for each L1 block we end up issuinguint256 issuance = (_l1BlockOd - lastSyncedBlock) * _config.gasTargetPerL1Block
.lastSyncedBlock
is only updated every 5 blockshttps://github.com/code-423n4/2024-03-taiko/blob/f58384f44dbf4c6535264a472322322705133b11/packages/protocol/contracts/L2/TaikoL2.sol#L145-L152
If
anchor()
is called on 5 consecutive blocks we end up issuing in total15 * _config.gasTargetPerL1Block
instead of5 * _config.gasTargetPerL1Block
.When the calculated base fee is compared to the
block.basefee
the following happens:If
block.basefee
reports the correct base fee this will end up halting the chain since they will not match.If
block.basefee
is using the same flawed calculation the chain continues but with a severely reduced and incorrect base fee.Here is a simple POC showing the actual issuance compared to the expected issuance. Paste the code into TaikoL1LibProvingWithTiers.t.sol and run
forge test --match-test testIssuance -vv
.Tools Used
foundry, vscode
Recommended Mitigation Steps
Issue exactly
config.gasTargetPerL1Block
for each L1 block.Assessed type
Other