Table of Links
Abstract and 1. Introduction
-
Background
2.1 Ethereum Primer
2.2 Whitelisted Address Verification
2.3 Taint Analysis on Smart Contracts and 2.4 Threat Model
-
Motivating Example and Challenges
3.1 Motivating Example
3.2 Challenges
3.3 Limitations of Existing Tools
-
Design of AVVERIFIER and 4.1 Overview
4.2 Notations
4.3 Component#1: Code Grapher
4.4 Component#2: EVM Simulator
4.5 Component#3: Vulnerability Detector
-
Evaluation
5.1 Experimental Setup & Research Questions
5.2 RQ1: Effectiveness & Efficiency
5.3 RQ2: Characteristics of Real-world Vulnerable Contracts
5.4 RQ3: Real-time Detection
-
Discussion
6.1 Threats to Validity and 6.2 Limitations
6.3 Ethical Consideration
-
Related Work
-
Conclusion, Availability, and References
6 Discussion
6.1 Threats to Validity
Scalability of AVVERIFIER. AVVERIFIER is specifically designed for the address verification vulnerability. However, due to the efficient taint analysis we implemented in AVVERIFIER, it can be easily extended to detect other kinds of vulnerabilities, like unchecked external calls and inadequate access controls. Moreover, AVVERIFIER can also be adopted on other blockchain platforms, i.e., EVM-compatible chains, like BSC, TRON, and AVAX. Consequently, AVVERIFIER is not a tool limited to the address verification vulnerability on Ethereum.
Candidate Contracts. When answering RQ1 and RQ2, we only choose around 5 million contracts as candidates. According to the statistics, there still exist millions of contracts. However, we think those already deployed ones without transactions are the worthless targets for attackers. However, in answering RQ3, i.e., deploying AVVERIFIER as a real-time detector, we take all newly deployed contracts as candidates.
6.2 Limitations
Although the AVVERIFIER is effective in identifying the address verification vulnerability, it still faces the following three limitations:
Dynamic Parameters Verification Mechanism. Some smart contracts employ dynamic parameters verification mechanisms, like digital signatures, which require loading data into memory. To this end, the size of CALLDATA is unknown beforehand, posing challenges to AVVERIFIER as the variable length of CALLDATA leads to unpredictable offsets, making it difficult to track variable arguments in dynamic memory. Currently, for such dynamic parameters, AVVERIFIER concretizes their length to obtain the final results. Due to its possibility of introducing false negatives, we take this as one of our future research directions.
Scalability. AVVERIFIER is a tool specifically designed to identify the address verification vulnerability. As such, currently, it cannot be used for identifying other smart contract vulnerabilities directly. However, because we have implemented a comprehensive set of taint propagation rules, AVVERIFIER can be easily extended to other smart contract security problems.
Auto-exploitation. While AVVERIFIER can efficiently and accurately identify the address verification vulnerability and the entry point, it cannot automatically generate exploitation yet. Currently, all identified contracts still require a comprehensive manual confirmation to determine if they are truly vulnerable and exploitable. However, we can take advantage of other techniques, like fuzzing and symbolic execution, to help AVVERIFIER generate exploitations and CALLDATA based on the generated results. We believe it is a meaningful research area.
6.3 Ethical Consideration
Due to the anonymity of blockchain, it is only possible to contact the developers of open-sourced projects. Thus, we have tried our best to contact developers of vulnerable contracts through all possible and usable media, like mail, official website, and twitter, with more than 500 transactions in history. Unfortunately, after we warned 48 developers once after the identification and manual recheck, we did not receive any responses from them within 2 weeks. Where we deploy a real-time detector on Ethereum and BSC, we observed that AVVERIFIER has raised alarms several times, like the one shown in §5.4.2. However, it is impossible to reach its developers privately. Moreover, we cannot initiate a transaction to notify the developer, because it will also notify malicious users that there is a possible victim. Thus, we urge collaboration with blockchain security companies for the secure and efficient disclosure of vulnerabilities.
Authors:
(1) Tianle Sun, Huazhong University of Science and Technology;
(2) Ningyu He, Peking University;
(3) Jiang Xiao, Huazhong University of Science and Technology;
(4) Yinliang Yue, Zhongguancun Laboratory;
(5) Xiapu Luo, The Hong Kong Polytechnic University;
(6) Haoyu Wang, Huazhong University of Science and Technology.
