Technical analysis of the fork event caused by the attack on Ethereum

At around 20:50 Beijing time on August 27, 2021 (block height 13107518), Ethereum suddenly forked. We analyzed the code version modification of Geth and the transaction that caused the fork (0x1cb6fb36633d270edefc04d048145b4298e67b8aa82a9e5ec4aa1435dd770ce4) to clarify the root cause of the Ethereum fork: the old version of Geth did not consider the processing of parameter values ​​under special circumstances (corner case) when processing precompiled contract calls, which caused overlapping copies and abnormal return values. The vulnerability (CVE-2021-39137) has been submitted to Geth officials. The details have not been disclosed yet, but the attacker has already exploited the vulnerability to carry out the attack. We believe that timely analysis and disclosure are necessary, and we hope that our analysis can provide the community with the necessary understanding and help.

Attack Analysis

Using our online analysis tool, we can see that:

Figure 1

This transaction executed a carefully constructed STATICCALL. The attacker set addr to 0x04 (precompiled contract dataCopy), inOffset to 0, inSize to 32, retOffset to 7, and retSize to 32.

Figure 2

Since the target address of STATICCALL is a precompiled contract, RunPrecompiledContract in Figure 2 will be executed.

Figure 3

Figure 4

According to the code in Figures 3 and 4, we can see that the actual logic executed by the precompiled contract 0x04 is simply to return in (pointer).

Figure 5

Figure 6

Figure 5 shows the execution process of STATICCALL. Line 753 is the entry point for executing the precompiled contract. Line 751’s args points to the pointer of the inOffset ~ inOffset + inSize area in the EVM’s Memory, which means that args points to Mem[0:32].

According to Figure 6 and the previous analysis of precompiled contract 0x04 (dataCopy), we can know that the return value ret of line 753 is exactly the same pointer as args, and also points to Mem[0:32].

• In the 1.10.7 version of Geth (with a bug): Line 762 assigns the value pointed to by ret to the retOffset ~ retOffset + retOffset area in the EVM's Memory, that is, assigns the value of Mem[0:32] to Mem[7:7+32]. Since ret is a pointer to Mem[0:32], this time Memory.Set modifies the value of Mem[7:32], which also modifies the value pointed to by ret. Therefore, the ret returned in line 771 is no longer the ret at the end of the precompiled contract execution.

• In the 1.10.8 version of Geth (bug-free): Line 766 was added: ret = common.CopyBytes (ret), which makes a deep copy of the value in Mem[0:32] and assigns it to ret. Then the Memory.Set executed in line 767 will only modify Memory but not ret. The ret returned in line 771 is the correct ret.

Summarize

Through the analysis of the entire attack process and the Geth source code, we believe that the root cause is that the old version of Geth did not consider the handling of abnormal values ​​when processing the call of the precompiled contract, which led to the attacker using the vulnerability to implement overlapping copies, affecting the return value and eventually leading to the fork. Since Geth is the basis of public chains such as BSC, HECO, and Polygon, the impact of this vulnerability is very wide. At present, various public chains have also launched upgrades and patches. We also call on all relevant nodes to upgrade and patch as soon as possible to ensure the security of the infrastructure.