Full Report
The primary smart contract development language is Solidity. However, this contains many, many footguns that the developers of Stacks have tried to fix. This post goes into he design of their custom language Clarity, and the vulnerabilities that it helps prevent. The most famous vulnerability in Solidity is reentrancy. This is when a smart contract can call into another contract that eventually recalls your contract. This allows for the manipulation of the state that shouldn't be possible. Clarity doesn't allow for reentrancy at all. Integer overflows/underflows are prevented at the VM level as well. Clarity requires external contract calls to be explicitly handled. This ensures that errors are handled properly. On top of this, all functions return something similar to a Result type in Rust. This makes the error handling very explicit in Clarity. All code in Clarity knows the exact amount of gas before execution. To do this, unbounded iterations and dynamic lists are not possible. This prevents many standard classes of DoS vulnerabilities in Solidity. Clarity contains a native VRF function that the VM can call to obtain actual random data. This prevents weird randomness vulnerabilities like in Ethereum-based blockchains. The final section is my favorite: unknown unknowns. To prevent users from getting exploited, they have post-conditions on the outcome of the contract execution. If these are violated, then the contract just fails. This helps proactively protect assets even if you don't know the vector. Overall, a good post on the benefits of the Clarity language.
Analysis Summary
# Vulnerability: Multiple Recurring Smart Contract Design Flaws (Solidity/EVM)
## CVE Details
- **CVE ID**: N/A (General architectural vulnerabilities; specific historical instances include the DAO Hack and Parity Wallet Breach)
- **CVSS Score**: 10.0 (High/Critical - based on historical exploit impact)
- **CWE**: CWE-691 (Insufficient Control Flow Management/Reentrancy), CWE-190 (Integer Overflow), CWE-703 (Improper Check or Handling of Exceptional Conditions)
## Affected Systems
- **Products**: Ethereum Virtual Machine (EVM) compatible blockchains, Solidity-based smart contracts.
- **Versions**: Various; specifically versions prior to Solidity 0.8.0 (for arithmetic) and contracts not utilizing standard OpenZeppelin protection libraries.
- **Configurations**: Contracts allowing external calls to untrusted addresses, utilizing `delegatecall` in proxy patterns, or lacking explicit arithmetic checks.
## Vulnerability Description
The article highlights several inherent "footguns" in traditional smart contract languages (like Solidity) that lead to systemic vulnerabilities:
1. **Reentrancy**: State manipulation occurring when an external call allows the called contract to re-enter the original contract before the first execution completes.
2. **Arithmetic Errors**: Integer overflows and underflows that can lead to unintended token minting or balance theft.
3. **Access Control & Visibility**: Insecure default settings and fallback functions that allow unauthorized access to sensitive logic (e.g., `tx.origin` or `delegatecall` flaws).
4. **Unbounded Iteration**: Dynamic lists or loops that can exceed gas limits, leading to Permanent Denial of Service (DoS) for the contract.
5. **Weak Randomness**: Reliance on easily manipulated blockchain variables (block hashes) for "random" data.
## Exploitation
- **Status**: Exploited in the wild (The DAO, Parity Multisig hacks).
- **Complexity**: Medium to High (Requires understanding of the EVM call stack and state transitions).
- **Attack Vector**: Network (Blockchain transactions).
## Impact
- **Confidentiality**: Low (Blockchain data is generally public).
- **Integrity**: Critical (Complete corruption of contract state and unauthorized asset transfers).
- **Availability**: Critical (Permanent freezing of funds due to gas limits or locked logic).
## Remediation
### Patches
- **Solidity 0.8.0+**: Now includes built-in checked arithmetic to prevent overflow/underflow.
- **OpenZeppelin Libraries**: Use `ReentrancyGuard` and `AccessControl` modules.
### Workarounds
- **Clarity Language Transitio**: Migration to the Clarity language (Stacks blockchain) which addresses these flaws at the VM level:
- **No Reentrancy**: Disallowed by language design.
- **Decidability**: Turing incomplete, allowing exact gas calculation and preventing DoS via unbounded loops.
- **Post-conditions**: User-defined rules that revert transactions if unauthorized asset movements occur, regardless of the exploit vector.
## Detection
- **Indicators of Compromise**: Unexpected `Transfer` events, contract balances dropping to zero, or repeated calls within a single transaction trace.
- **Detection methods and tools**:
- Static analysis (Slither, Mythril).
- Formal verification of contract logic.
- Clarity’s built-in type checker and static analysis of the call graph.
## References
- **Stacks Foundation Advisory**: hxxps[:]//stacks[.]org/bringing-clarity-to-8-dangerous-smart-contract-vulnerabilities/
- **Clarity Documentation**: hxxps[:]//docs[.]stacks[.]co/
- **DASP Top 10**: hxxps[:]//www[.]dasp[.]co/