It is possible to artificially inflate one's balance, compromising the integrity of the KIB token entirely. The vulnerability arises from how the balances are updated and utilize "stale" values that were loaded into memory. As such, a self-transfer would load the newFromBalance as the current balance of the user minus the amount and the newToBalance as the current balance of the user plus the amount.
A user can send their entire balance to themselves and cause the final assignments of the _transfer function to assign to _baseBalances[to] the value of newToBalance, enabling them to double their balance on each invocation.
As an additional issue, the totalSupply will remain unchanged thus not only allowing the user to acquire an unfair amount of tokens but also retaining the existing total supply which can have other consequences i.e. during burn operations.
Proof of Concept
Any transfer invocation to self or transferFrom two identical addresses will activate this vulnerability and cause the user to increase their balance by whatever amount was input to the function, up to their current balance.
Tools Used
Manual review of the codebase.
Recommended Mitigation Steps
We advise the prohibition of a self-transfer to avoid this issue entirely. The issue solely arises from self-transfers and as such, preventing them is a sufficient alleviation to this vulnerability.
Lines of code
https://github.com/code-423n4/2023-02-kuma/blob/main/src/kuma-protocol/KIBToken.sol#L288-L291
Vulnerability details
Impact
It is possible to artificially inflate one's balance, compromising the integrity of the KIB token entirely. The vulnerability arises from how the balances are updated and utilize "stale" values that were loaded into memory. As such, a self-transfer would load the
newFromBalance
as the current balance of the user minus theamount
and thenewToBalance
as the current balance of the user plus theamount
.A user can send their entire balance to themselves and cause the final assignments of the
_transfer
function to assign to_baseBalances[to]
the value ofnewToBalance
, enabling them to double their balance on each invocation.As an additional issue, the
totalSupply
will remain unchanged thus not only allowing the user to acquire an unfair amount of tokens but also retaining the existing total supply which can have other consequences i.e. during burn operations.Proof of Concept
Any
transfer
invocation to self ortransferFrom
two identical addresses will activate this vulnerability and cause the user to increase their balance by whateveramount
was input to the function, up to their current balance.Tools Used
Manual review of the codebase.
Recommended Mitigation Steps
We advise the prohibition of a self-transfer to avoid this issue entirely. The issue solely arises from self-transfers and as such, preventing them is a sufficient alleviation to this vulnerability.