This project aims to provide a valuable resource for Web3 developers and security analysts by facilitating their understanding of exploitable bugs in smart contracts. We conduct a thorough analysis of exploitable bugs extracted from code4rena and classify each bug according to its nature.
Our initial research suggests that a notable proportion of exploitable bugs in smart contracts are functional bugs, which cannot be detected using simple and general oracles like reentrancy. We aim to raise awareness about the significance of such bugs and encourage practitioners to develop more sophisticated and nuanced automatic semantical oracles to detect them.
𝙰 𝚜𝚒𝚐𝚗𝚒𝚏𝚒𝚌𝚊𝚗𝚝 𝚗𝚞𝚖𝚋𝚎𝚛 𝚘𝚏 𝚎𝚡𝚙𝚕𝚘𝚒𝚝𝚊𝚋𝚕𝚎 𝚋𝚞𝚐𝚜 𝚒𝚗 𝚜𝚖𝚊𝚛𝚝 𝚌𝚘𝚗𝚝𝚛𝚊𝚌𝚝𝚜 𝚏𝚊𝚕𝚕 𝚞𝚗𝚍𝚎𝚛 𝚝𝚑𝚎 𝚌𝚊𝚝𝚎𝚐𝚘𝚛𝚢 𝚘𝚏 𝚏𝚞𝚗𝚌𝚝𝚒𝚘𝚗𝚊𝚕 𝚋𝚞𝚐𝚜, 𝚠𝚑𝚒𝚌𝚑 𝚌𝚊𝚗𝚗𝚘𝚝 𝚋𝚎 𝚍𝚎𝚝𝚎𝚌𝚝𝚎𝚍 𝚞𝚜𝚒𝚗𝚐 𝚜𝚒𝚖𝚙𝚕𝚎 𝚊𝚗𝚍 𝚐𝚎𝚗𝚎𝚛𝚊𝚕 𝚘𝚛𝚊𝚌𝚕𝚎𝚜.
Please be aware that this repository is currently undergoing active development, and the data may change over time due to ongoing code4rena contests.
We plan to compile an extensive list of vulnerability detection techniques that prioritize the development of semantical oracles for smart contracts.
We warmly welcome any additional suggestions or contributions from the community to help expand and improve the list.
- Finding Permission Bugs in Smart Contracts with Role Mining, which addresses access control issues.
- AChecker: Statically Detecting Smart Contract Access Control Vulnerabilities, which addresses access control issues.
The dataset is organized into four folders:
- papers/: contains our ICSE23 paper summarizing our preliminary results, as well as the supplementary material for the paper.
- results/: contains the bug classification in bugs.csv and the description for each contest in contests.csv.
- contracts/: contains all the smart contracts that we examined, using the version at the time of the contest.
- reports/: contains all the reports provided by code4rena.
We classify the surveyed bugs into three main categories based on their nature:
- Out-of-scope bugs (denoted by O)
- Bugs with simple and general testing oracles (denoted by L)
- Bugs that require high-level semantical oracles (denoted by S)
Please note that classifying functional bugs can be ambiguous, and we welcome any suggestions for improving our classification standards. We have also updated our classification since the ICSE23 paper, and we encourage you to refer to our current classification guidelines for more information.
These are bugs that fall outside the scope of our study and are thus not analyzed further.
- O1: These vulnerabilities can only be exploited by privileged users (e.g., rug pull), or when the privileged users make mistakes (e.g., applying incorrect configuration during deployment).
- O2: We cannot access the source code of the project.
- O3: These vulnerabilities can only be exploited with further actions by victim users (e.g., EIP-4626 inflation attacks)
- O4: Bugs that occur in off-chain components.
- O5: Typo or trivial bugs that render the contract non-deployable or non-functional. We believe these types of bugs are unlikely to occur in contracts that are ready for audit or have been deployed.
- O6: Bugs that are not considered as such by the project. This can be due to disagreements between the auditors and the project (common in early contests), no explicit code affected by the bug, or intentional behavior that aligns with the business model (where the business model may be flawed).
- O7: Doubtful findings, which we believe may be invalid, duplicated, or non-critical (common in early contests).
These are bugs that can be detected using simple and general oracles and do not require an in-depth understanding of the code semantics.
- L1: Reentrancy.
- L2: Rounding issues or precision loss.
- L3: Bugs that are caused by using uninitialized variables.
- L4: Bugs that are caused by exceeding the gas limitation.
- L5: Storage collision and confusion between proxy and implementation.
- L6: Arbitrary external function call.
- L7: Integer overflow and underflow.
- L8: Revert issues caused by low-level calls or external libraries.
- L9: Bugs that are caused by writing to memory that does not apply to the storage.
- LA: Cryptographic issues.
- LB: Using
tx.origin.
These are bugs that require high-level semantical oracles to detect, as they arise from inconsistencies between the code implementation and the business model.
- S1: Price oracle manipulation.
- S1-1: AMM price oracle manipulation.
- S1-2: Sandwich attack.
- S1-3: Non-AMM price oracle manipulation.
- S2: ID-related violations.
- S2-1: ID can be arbitrarily set by users or lack of ID validation. ID can also be a project-specified variable (e.g., hash) or an address.
- S2-2: Shared resource (e.g., token) without proper locks.
- S2-3: ID uniqueness violation (i.e., an ID should be unique but it is not).
- S3: Erroneous state updates.
- S3-1: Missing state update.
- S3-2: Incorrect state updates, e.g., a state update that should not be there.
- S4: Business-flow atomicity violations.
- S4-1: Lack of proper locks for a business flow consisting of multiple transactions.
- S5: Privilege escalation and access control issues.
- S5-1: Users can update privileged state variables arbitrarily (caused by lack of ID-unrelated input sanitization).
- S5-2: Users can invoke some functions at a time they should not be able to do so.
- S5-3: Privileged functions can be called by anyone or at any time.
- S6: Erroneous accounting.
- S6-1: Incorrect calculating order.
- S6-2: Returning an unexpected value that deviates from the expected semantics specified for the contract.
- S6-3: Calculations performed with incorrect numbers (e.g.,
x = a + b==>x = a + c). - S6-4: Other accounting errors (e.g.,
x = a + b==>x = a - b).
- SE: Broken business models due to unexpected operations
- SE-1: Unexpected function invocation sequences (e.g., external calls to dependent contracts).
- SE-2: Unexpected environment or contract conditions (e.g., ChainLink returning outdated data or significant slippage occurring).
- SE-3: A given function is invoked multiple times unexpectedly.
- SE-4: Unexpected function arguments.
- SC: Contract implementation-specific bugs. These bugs are difficult to categorize into the above categories.
We welcome all types of contributions to our project, including but not limited to:
- Suggesting new reference techniques for prioritizing smart contract vulnerability detection with semantical oracles.
- Adding newly disclosed code4rena contest bugs.
- Suggesting improvements to the classification standard
- Correcting mislabeled bugs
Further details can be found in our contribution guidelines.
- Zhuo Zhang, Brian Zhang, Wen Xu, Zhiqiang Lin, "Demystifying Exploitable Bugs in Smart Contracts." In Proceedings of the 45th International Conference on Software Engineering, 2023.
The ICSE23 paper presented our preliminary investigation, which focused on vulnerability detection tools that were available before August 2022 and capable of analyzing smart contracts before deployment. However, we are now also investigating and recommending tools that work on post-deployment contracts (e.g., SPCon).
Our dataset and classification standards are being actively developed, and we welcome contributions from the community to help improve them. Despite these updates, our conclusions, as presented in the ICSE23 paper, remain unchanged.
We would like to extend our sincere thanks to code4rena for making this valuable information publicly available.