Minority split 2021-08-27 post mortem¶
This is a post-mortem concerning the minority split that occurred on Ethereum mainnet on block 13107518, at which a minority chain split occurred.
Timeline¶
- 2021-08-17: Guido Vranken submitted a bounty report. Investigation started, root cause identified, patch variations discussed.
- 2021-08-18: Made public announcement over twitter about upcoming security release upcoming Tuesday. Downstream projects were also notified about the upcoming patch-release.
- 2021-08-24: Released v1.10.8 containing the fix on Tuesday morning (CET). Erigon released v2021.08.04.
- 2021-08-27: At 12:50:07 UTC, issue exploited. Analysis started roughly 30m later,
Bounty report¶
2021-08-17 RETURNDATA corruption via datacopy¶
On 2021-08-17, Guido Vranken submitted a report to bounty@ethereum.org. This coincided with a geth-meetup in Berlin, so the geth team could fairly quickly analyse the issue.
He submitted a proof of concept which called the dataCopy
precompile, where the input slice and output slice were overlapping but shifted. Doing a copy
where the src
and dest
overlaps is not a problem in itself, however, the returnData
slice was also using the same memory as a backing-array.
Technical details¶
During CALL-variants, geth
does not copy the input. This was changed at one point, to avoid a DoS attack reported by Hubert Ritzdorf, to avoid copying data a lot on repeated CALL
s – essentially combating a DoS via malloc
. Further, the datacopy precompile also does not copy the data, but just returns the same slice. This is fine so far.
After the execution of dataCopy
, we copy the ret
into the designated memory area, and this is what causes a problem. Because we’re copying a slice of memory over a slice of memory, and this operation modifies (shifts) the data in the source – the ret
. So this means we wind up with corrupted returndata.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Summary¶
A memory-corruption bug within the EVM can cause a consensus error, where vulnerable nodes obtain a different stateRoot
when processing a maliciously crafted transaction. This, in turn, would lead to the chain being split: mainnet splitting in two forks.
Handling¶
On the evening of 17th, we discussed options on how to handle it. We made a state test to reproduce the issue, and verified that neither openethereum
, nethermind
nor besu
were affected by the same vulnerability, and started a full-sync with a patched version of geth
.
It was decided that in this specific instance, it would be possible to make a public announcement and a patch release:
- The fix can be made pretty ‘generically’, e.g. always copying data on input to precompiles.
- The flaw is pretty difficult to find, given a generic fix in the call. The attacker needs to figure out that it concerns the precompiles, specifically the datcopy, and that it concerns the
RETURNDATA
buffer rather than the regular memory, and lastly the special circumstances to trigger it (overlapping but shifted input/output).
Since we had merged the removal of ETH65
, if the entire network were to upgrade, then nodes which have not yet implemented ETH66
would be cut off from the network. After further discussions, we decided to:
- Announce an upcoming security release on Tuesday (August 24th), via Twitter and official channels, plus reach out to downstream projects.
- Temporarily revert the
ETH65
-removal. - Place the fix into the PR optimizing the jumpdest analysis 233381.
- After 4-8 weeks, release details about the vulnerability.
Exploit¶
At block 13107518, mined at Aug-27-2021 12:50:07 PM +UTC, a minority chain split occurred. The discord user @AlexSSD7 notified the allcoredevs-channel on the Eth R&D discord, on Aug 27 13:09 UTC.
At 14:09 UTC, it was confirmed that the transaction 0x1cb6fb36633d270edefc04d048145b4298e67b8aa82a9e5ec4aa1435dd770ce4
had triggered the bug, leading to a minority-split of the chain. The term ‘minority split’ means that the majority of miners continued to mine on the correct chain.
At 14:17 UTC, @mhswende tweeted out about the issue [2].
The attack was sent from an account funded from Tornado cash.
It was also found that the same attack had been carried out on the BSC chain at roughly the same time – at a block mined 12 minutes earlier, at Aug-27-2021 12:38:30 PM +UTC.
The blocks on the ‘bad’ chain were investigated, and Tim Beiko reached out to those mining operators on the minority chain who could be identified via block extradata.
Lessons learned¶
Disclosure decision¶
The geth-team have an official policy regarding vulnerability disclosure.
The primary goal for the Geth team is the health of the Ethereum network as a whole, and the decision whether or not to publish details about a serious vulnerability boils down to minimizing the risk and/or impact of discovery and exploitation.
In this case, it was decided that public pre-announce + patch would likely lead to sufficient update-window for a critical mass of nodes/miners to upgrade in time before it could be exploited. In hindsight, this was a dangerous decision, and it’s unlikely that the same decision would be reached were a similar incident to happen again.
Disclosure path¶
Several subprojects were informed about the upcoming security patch:
- Polygon/Matic
- MEV
- Avalanche
- Erigon
- BSC
- EWF
- Quorum
- ETC
- xDAI
However, some were ‘lost’, and only notified later
- Optimism
- Summa
- Harmony
Action point: create a low-volume geth-announce@ethereum.org email list where dependent projects/operators can receive public announcements. - This has been done. If you wish to receive release- and security announcements, sign up here
Fork monitoring¶
The fork monitor behaved ‘ok’ during the incident, but had to be restarted during the evening.
Action point: improve the resiliency of the forkmon, which is currently not performing great when many nodes are connected.
Action point: enable push-based alerts to be sent from the forkmon, to speed up the fork detection.
Links¶
- [1] https://twitter.com/go_ethereum/status/1428051458763763721
- [2] https://twitter.com/mhswende/status/1431259601530458112
Appendix¶
Subprojects¶
The projects were sent variations of the following text:
1 2 3 4 5 6 7 8 9 |
|
Patch¶
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
|
Statetest to test for the issue¶
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 |
|