Submitted by hyh, also found by 0x1f8b, 0x29A, cccz, Chom, csanuragjain, hansfriese, itsmeSTYJ, kenzo, pashov, shenwilly, Soosh, and unforgiven
Illuminate PT burns shares from a user supplied address account instead of users account. With such a discrepancy a malicious user can burn all others user shares by having the necessary shares on her balance, while burning them from everyone else.
Setting the severity to be high as this allows for system-wide stealing of users funds.
Redeemers Illuminate redeem() checks the balance of msg.sender, but burns from the balance of user supplied o address:
https://github.com/code-423n4/2022-06-illuminate/blob/912be2a90ded4a557f121fe565d12ec48d0c4684/redeemer/Redeemer.sol#L114-L128
L120:
L126:
o address isnt validated and used as provided.
Burning proceeds as usual, Illuminate PT burns second argument a from the first argument f, i.e. fs balance to be reduced by a:
https://github.com/code-423n4/2022-06-illuminate/blob/912be2a90ded4a557f121fe565d12ec48d0c4684/marketplace/ERC5095.sol#L121-L127
https://github.com/code-423n4/2022-06-illuminate/blob/912be2a90ded4a557f121fe565d12ec48d0c4684/marketplace/ERC5095.sol#L7
https://github.com/code-423n4/2022-06-illuminate/blob/912be2a90ded4a557f121fe565d12ec48d0c4684/marketplace/ERC20.sol#L187-L196
This way a malicious user owning some Illuminate PT can burn the same amount of PT as she owns from any another account, that is essentially from all other accounts, obtaining all the underlying tokens from the system. The behavior is somewhat similar to the public burn case.
o address looks to be not needed in Illuminate PT case.
Consider burning the shares from msg.sender, for example:
https://github.com/code-423n4/2022-06-illuminate/blob/912be2a90ded4a557f121fe565d12ec48d0c4684/redeemer/Redeemer.sol#L125-L126
sourabhmarathe (Illuminate) confirmed
