Is the "ruthless character" DEX under the DeFi wav safe enough?

Today, with the growing interest in DeFi, DEXs, or decentralized exchanges, are all the rage. They solve the common CEX (ie centralized exchange) problem, so we also ask, is DEX safe enough?

After explaining the security issues of the token itself in the previous article (pure dry goods sharing (1) | The basics of DEFI security issues), now let's talk about the security issues that DEX may have when exchanging tokens. At present, the main security problems faced by DEX can be roughly divided into two categories:

(1) Security issues in the DEX project itself.

(2) As a third-party protocol, security issues arise when interacting with other DEFI projects.

This article will introduce the first category of security issues.

Contract Part.1

-Decentralized Exchange

reentrancy vulnerability

We also mentioned the reentrancy vulnerability in the previous article, and it is a classic vulnerability that needs to be guarded against. Compared with the re-entry of ordinary tokens, the main manifestation of Uniswap's re-entry vulnerability is as follows: an attacker initiates a second exchange before using Uniswap to update the price in a timely manner in an exchange transaction. Since Uniswap has not updated the price at this time, the The number of tokens that can be exchanged for the second exchange is more than the normal exchange. In addition, in Uniswap's reentrancy attack, the attacker may only obtain a small profit using a single transaction, so the attacker often tends to use flash loans or circular arbitrage to expand the results.

Take the imBTC attack incident as an example. This incident was caused by the fact that Uniswap V1 did not fully consider the contract callback when calling the ERC777 series of tokens.

The specific performance is as follows: when the attacker uses imBTC tokens to exchange ETH (as shown in Figure 1), the contract first calculates the correct amount of ETH through the self.getInputPrice function and sends the ETH to the target address, and then calls the self.token.transferFrom function. Call the _callTokensToSend function of the imBTC contract (as shown in Figure 2), and the _callTokensToSend function will call the user-specified contract to store imBTC tokens. Therefore, if an attacker deploys a storage contract and rewrites the TokensToSend function, then when exchanging tokens, the pair (a transaction pair consisting of two tokens) contract calls the storage contract deployed by the attacker, and the pair can be called back for secondary exchange , and the pair contract account book has not been updated during the second exchange, so that the amount of ETH calculated is more than the normal exchange, so as to make a profit.