Full Report
CoinVertible is a euro-pegged stablecoin. Although this sounds like a good idea, the authors of this post found some horrible findings in a brief glance. The eco-system is highly permissioned. As a result, EURCV requires that all transfers and transfer approvals be validated by the central authority registrar. The function rejectTransfer() has a miscalculation in it. In particular, the wrong entity is used for the approval call. Additionally, the rejectTransfer() function cannot reject transfers if the allowance is extremely high. This is because the math done is allowance + transferRequest.value. This would revert with an integer overflow, making it impossible to reject the transaction. The second vulnerability mentioned is the lack of a two-step ownership transfer. This is normally done by setting the recipient but forcing the contract to claim the role to finalize the transfer. This is used to prevent accidental self-DoS attacks. The contract suffers from the standard ERC20 race condition for setting the allowance of a user too. Instead of setting the values directly, simply increasing or decreasing the values should be done. There were a few other small things, like the transfer event being missing and a frontrunning gas griefing issue. Overall, fun issues with good impact! Although, there is no direct loss of funds found.
Analysis Summary
# Vulnerability: Multiple Logic and Security Flaws in SG Forge CoinVertible (EURCV)
## CVE Details
- **CVE ID:** Not Assigned (Publicly disclosed via security research)
- **CVSS Score:** Estimated 7.5 - 8.2 (High)
- **CWE:** CWE-682 (Incorrect Calculation), CWE-190 (Integer Overflow), CWE-284 (Improper Access Control)
## Affected Systems
- **Products:** SG Forge CoinVertible (EURCV) Stablecoin
- **Versions:** Initial deployment (April 2023)
- **Configurations:** Ethereum mainnet contract address `0xf7790914dc335b20aa19d7c9c9171e14e278a134`
## Vulnerability Description
Multiple flaws exist in the EURCV smart contract suite:
1. **Accounting Error in `rejectTransfer()`:** The function incorrectly uses the `transferRequest.to` address instead of the `spender` address when recalculating allowances after a rejection. This can result in an unauthorized user receiving a spending allowance they were never granted.
2. **Denial of Service (DoS) via Integer Overflow:** In `rejectTransfer()`, the logic performs `allowance + transferRequest.value`. If a user already has a maximum allowance, this math reverts the transaction, preventing the registrar from ever rejecting a transfer and potentially locking user funds.
3. **Single-Step Ownership Transfer:** The registrar role is transferred in a single step. If an incorrect or inaccessible address is provided, the contract's administrative functions (which are required for all transfers) become permanently "bricked."
4. **ERC20 Race Condition:** The contract uses the standard `approve()` mechanism rather than `increaseAllowance`/`decreaseAllowance`, making it susceptible to front-running allowance changes.
## Exploitation
- **Status:** PoC described in research; no known exploitation in the wild at time of report.
- **Complexity:** Medium
- **Attack Vector:** Network (Smart Contract Interaction)
## Impact
- **Confidentiality:** None
- **Integrity:** High (Unauthorized allowance grants and incorrect accounting)
- **Availability:** High (Potential to brick the registrar role or block the rejection of transactions via overflow)
## Remediation
### Patches
- No specific patch version listed; requires a redeployment of the SmartCoin and Whitelist contracts with corrected logic.
### Workarounds
- **Registrar Caution:** The central authority must exercise extreme care when calling `updateRegistrar`.
- **Users:** Minimize allowances to only what is necessary to reduce the risk of the overflow DoS in the `rejectTransfer` function.
## Detection
- **Indicators of Compromise:** Unexpected allowance values for users who were not the intended "spender" in a rejected `transferFrom` call.
- **Detection methods:** Monitoring for failed `rejectTransfer` calls on-chain due to "Arithmetic over/underflow" errors. Static analysis tools (Slither, Mythril) can detect the lack of two-step ownership and the missing ERC20 Transfer event.
## References
- **Vendor Advisory:** hxxps://www.sgforge[.]com/societe-generale-forge-launches-coinvertible-the-first-institutional-stablecoin-deployed-on-a-public-blockchain/
- **Original Research:** hxxps://medium[.]com/@jat9292/sg-forges-coinvertible-stablecoin-or-stumblecoin-31e4b627fa67
- **Contract Code:** hxxps://etherscan[.]io/address/0xf7790914dc335b20aa19d7c9c9171e14e278a134#code