Closed code423n4 closed 1 year ago
trust1995 changed the severity to QA (Quality Assurance)
trust1995 marked the issue as grade-b
Yes we trust the user to pass a correct mintTo. There are many addresses aside from address(0) that would leave the user unable to access the funds.Probably won't fix.
wilsoncusack marked the issue as sponsor acknowledged
Lines of code
https://github.com/with-backed/papr/blob/9528f2711ff0c1522076b9f93fba13f88d5bd5e6/src/PaprToken.sol#L24-L26 https://github.com/with-backed/papr/blob/9528f2711ff0c1522076b9f93fba13f88d5bd5e6/src/PaprController.sol#L144
Vulnerability details
Impact
In PaprToken contract, the
mint(to, amount)
function didn't check ifto
exists.mint()
calls_mint(to, amount)
, which didn't checkto
either. So, the responsibility of making sureto
is acutally an intended correct address is fully on the caller. Thus, PaprTokens might be possibly minted to:POC
In some scenarios, the above situation may happen. For example, a user calls
PaprController.increaseDebt(mintTo, asset, amount,oracleInfo)
which inturn calls_increaseDebt({account: msg.sender, asset: asset, mintTo: mintTo, amount: amount, oracleInfo: oracleInfo})
, wheremintTo
is the address to mint the debt to, i.e. PaprToken receiver. However,mintTo
was not checked in the whole call chain. This leaves all possibilites possible:mintTo
to address(0), those tokens will be lost forever;minTo
to the PaprToken address (this has happened a lot in blockchain world and has locked numerous ERC20 tokens), minted tokens will be locked in the contract;minTo
to any valid non-existing address, the minted token will be trapped in the contract.Tools Used
Manual audit.
Recommended Mitigation Steps
mintTo
is a non-zero address;rescue
functionality which is able to rescue any tokens trapped in PaprToken contract with some policies in place.