Resolving the Multiple Withdrawal Attack on ERC20 Tokens

Abstract

Custom tokens are an integral component of decentralized applications (dapps) deployed on Ethereum and other blockchain platforms. For Ethereum, the ERC20 standard is a widely used token interface and is interoperable with many existing dapps, user interface platforms, and popular web applications (e.g., exchange services). An ERC20 security issue, known as the multiple withdrawal attack, was raised on GitHub and has been open since November 2016. The issue concerns ERC20's defined method approve() which was envisioned as a way for token holders to give permission for other users and dapps to withdraw a capped number of tokens. The security issue arises when a token holder wants to adjust the amount of approved tokens from N to M (this could be an increase or decrease). If malicious, a user or dapp who is approved for N tokens can frontrun the adjustment transaction to first withdraw N tokens, then allow the approval to be confirmed, and withdraw an additional M tokens. In this paper, we evaluate 10 proposed mitigations for this issues and find that no solution is fully satisfactory. We then propose 2 new solutions that mitigate the attack, one of which fully fulfills constraints of the standard, and the second one shows a general limitation in addressing this issue from ERC20's approve method.Index Terms-Ethereum; ERC20 tokens; Blockchain; 3. A widely used lock-free synchronization strategy that allows comparing and setting values atomically.

EVchain: An Anonymous Blockchain-Based System for Charging-Connected Electric Vehicles

“…Then, to verify their true identities, we use sig PK U .PKI/ as the digital signature for the users, and Sign R to represent the ring signature. The three tokens [17] are represented by T v-s , T s-c , and T c-p . Other basic notations are introduced in the following.…”

TokenHook: Secure ERC-20 smart contract

“…Using these functions in an undesirable situation (i.e., front-running or racecondition) can result in allowing a malicious authorized entity to transfer more tokens than the owner wanted. There are several suggestions to extend ERC-20 standard (e.g., MonolithDAO [74] and its extension in OpenZeppelin [46]) by adding new functions (i.e., decreaseApproval() and increaseApproval()), however, securing transferFrom() method is the effective one while adhering specifications of the ERC-20 standard [55].…”

“…Without our counter-measure, an attacker can use a front-running attack [10,19] to transfer more tokens than what is intended (approved) by the token holder. We secure the transferFrom() function by tracking transferred tokens to mitigate the multiple withdrawal attack [55]. Securing the transferFrom() function is fully compliant with the ERC-20 standard without the need of introducing new functions such as decreaseApproval() and increaseApproval().…”

“…However these are not part of the ERC-20 standard and are not interoperable with other applications that expect to use approve() and transferFrom(). To-kenHook secures transferFrom() to prevent the attack (following [55]) and is interoperable with legacy DApps and web apps. Additionally, TokenHook mitigates the frozen Ether issue by introducing a withdraw() function, while ETH forced into the OpenZeppelin implementation is forever unrecoverable.…”

Tracking Counterfeit Cryptocurrency End-to-end

“…Friedhelm Victor et al [66] provided an overview of more than 64,000 ERC20 token networks and analyzed the top 1,000 from a graph perspective. Besides, there are some studies dedicated to optimizing the ERC-20 token standard [51,58] or using ERC-20 token contract to address practical issues [36,48]. For example, Mayer et al [51] proposed a proxy scaling solution for ERC-20 tokens named BatPay, which is suitable for micropayments in one-to-many and few-to-many scenarios and can reduce gas cost of transactions.…”