Abracadabra Rounding Error Attack

​

Description

• The protocol used a RebaseToken with two key components:
  • Elastic value: Represents the actual assets in debt
  • Base value: Represents total borrowed shares
• The User borrow mapping only stored borrowed shares per user, not the actual assets
• The design appeared to intentionally allow the protocol (or anyone) to modify the assets owed by users by changing the elastic value of the RebaseToken
• The repayForAll() function made this feature accessible to everyone

1. A critical rounding error allowed the attacker to inflate the base value without correspondingly adjusting the elastic value
2. This rounding error only manifests when elastic and base values significantly deviate from each other
3. The repayForAll() function was instrumental in creating this deviation

1. Inflate the base value (getting to elastic = 1, base = infinite)
2. Repay the outstanding assets (elastic = 0)
3. Leverage the first depositor problem, when elastic = 0, shares minted will be base = elastic
4. Borrow all assets in the protocol, because of first depositor problem, shares minted will be 1:1.
5. The attacker now has all assets in the protocol, but only owes a negligble share ratio to all outstanding shares.

• The solvency check _isSolvent() relied on comparing the attacker’s ratio of total borrowed shares
• The solvency check implicitly assumed elastic and base values would remain closely aligned
• With base set to infinite, the attacker’s debt ratio becomes negligible

​

Proposed Solution

function assertionNoDebtSharesIfNoDebt() public view {
    if (elastic == 0) {
        require(base == 0, "No debt shares if no debt");
    }
}