Summary
In Bor’s parallel EVM execution functionality there was a bug around ValidateVersion which might produce inconsistent block processing results for specific malicious crafted transactions between nodes implementing parallel execution and those which are not.
The bug could possibly cause parallel executors to compute a different block hash from a regular (serial) executor in some rare scenarios.
Root cause analysis
In parallel executor, StateDB.readMap was only written once at the first time MVRead is called thus all subsequent reads (which can be different from first read) were not considered by ValidateVersion, which could produce a wrong validation result and an invalid state being committed.
Basically it was possible for the same execution task to read from different versions of the same key path.
The flow of the exploit looks something like this:
- If the attacker is a unprivileged transaction sender:
A malicious transaction sender can send specially-crafted transactions to cause a block to be rejected by validators that run parallel EVM due to receipt or state root mismatch as block producer always executes transactions in sequential manner.
- If the attacker is a block producer
A malicious block producer can change the receipt and state roots to match the state it wants to commit. If the majority of validators run parallel EVM (> 2/3), there’s a chance that the malicious block will be recognized as a block in the canonical chain.
Resolution and recovery
A patch was successfully released on 18th September, with Bor tag 1.4.1
It consisted of a new check included in MVRead to make sure that all subsequent reads returned by MVHashmap.Read have the same version with that of the recorded first read. If not, the running incarnation should be marked as a “Read conflict detected”.
The patch was first tested on a devnet, then tested and rolled out on Amoy and Mainnet nodes simultaneously . A release announcement was shared, allowing all the validators to upgrade.