code-423n4 / 2022-12-backed-findings

1 stars 3 forks source link

PaprTokens may stuck in the contract, `rescue` functionality is desirable #281

Closed code423n4 closed 1 year ago

code423n4 commented 1 year ago

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 if to exists. mint() calls _mint(to, amount), which didn't check to either. So, the responsibility of making sure to 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}), where mintTo 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:

Tools Used

Manual audit.

Recommended Mitigation Steps

  1. verify mintTo is a non-zero address;
  2. implement a rescue functionality which is able to rescue any tokens trapped in PaprToken contract with some policies in place.
c4-judge commented 1 year ago

trust1995 changed the severity to QA (Quality Assurance)

c4-judge commented 1 year ago

trust1995 marked the issue as grade-b

wilsoncusack commented 1 year ago

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.

c4-sponsor commented 1 year ago

wilsoncusack marked the issue as sponsor acknowledged