Developers Forum for XinFin XDC Network: Sina Mahmoodi

Security analysis of PREVRANDAO opcode (block.prevrandao)

Sina Mahmoodi — Tue, 17 Dec 2024 11:29:05 +0000

Summary

Blockchains are deterministic machines. In an indeterministic world, many real-world use-cases require randomness in their decentralized applications. We would like to warn developers of using block.prevrandao in Solidity as a source of randomness in application such as lottery.

This post will highlight the reasoning for this and show results of an analysis into the history of the chain which aims to detect any vulnerable contracts. 11 contracts were detected to have invoked this opcode from block 70300000 to block 80300000 (10 million recent blocks). To the authors relief the contracts detected have no funds at stake.

Note on PREVRANDAO

Since block 76321000 the XDC network has activated a version of EIP-4399. It adds the PREVRANDAO opcode to the EVM, or rather replaces the existing opcode DIFFICULTY which was meaningless in the DPoS consensus algorithm of XDC. This new opcode is exposed to developers through block.prevrandao since Solidity v0.8.18.

PREVRANDAO essentially returns the keccak256 hash of the current block number. The reader might recognize that block numbers are always incrementing. This means that the value of PREVRANDAO can be precomputed for every future block in advance with negligible amount of computation.

The authors advise against using block.prevrandao (or block.difficulty) as a source of randomness in applications, specially when funds can be moved on a condition based on the random number, as in lottery applications.

Analysis of existing contracts

The goal here was to do a thorough analysis of the chain, find any contracts that might be using this opcode and assess their risk level, try to contact the maintainers if necessary.

A tool was developed (read more) which is able to crunch through past blocks and transactions and find any invocation of this (or any other) opcode. We ran this tool for the range of blocks between 70300000 to 80300000 and found the following contracts as potentially vulnerable:

After assessing there is no funds at risk we have decided to publish this post for the community's benefit. If you have any question about this please reach out.

Analysis of upstream security advisories

Sina Mahmoodi — Mon, 26 Aug 2024 09:13:36 +0000

We've gone through all the advisories published by the upstream go-ethereum repository to make sure XDC is not vulnerable to those issues. We can report that all the issues have been either patched in XDC or are not relevant. More details follow:

CVE-2024-32972: XDC is not affected as the issue was in the implementation of eth/68 and XDC is on eth/62 (eth/64 on testnet).
CVE-2023-40591: This has been patched by 4a333ad.
CVE-2022-29177: Fixed by https://github.com/XinFinOrg/XDPoSChain/pull/242.
CVE-2021-41173: Not relevant as XDC doesn't implement the snap protocol.
CVE-2021-39137: Fixed as part of https://github.com/XinFinOrg/XDPoSChain/pull/133.
CVE-2020-26265: The commit that introduced this issue (223b95) was never introduced to XDC.
CVE-2020-26264: To my knowledge no XDC LES servers are in production.
CVE-2020-28362: This has been an issue of XDC nodes built with Go <1.15.5 or <1.14.12. XDC cannot be built with such old versions anymore.
CVE-2020-26242: XDC is on v1.2.4 of holiman/uint256. The vulnerability had been resolved in v1.1.1. Furthermore the precompiles have not been migrated to use uint256.
CVE-2020-26241: Fixed in https://github.com/XinFinOrg/XDPoSChain/pull/255.
CVE-2020-26240: Not relevant as XDC is not on Ethash PoW algorithm.

[Proposal] Tracing bottleneck analysis

Sina Mahmoodi — Tue, 04 Jun 2024 14:19:55 +0000

XDC tracing bottleneck

It was reported that tracing a block will often take a long time and time out in the end which causes issue for indexers such as elliptic. Here we investigate the bottleneck and propose a solution.

Cause of issue

To trace a block/transaction the state needs to be prepared and it would be re-executed via EVM in addition to extra processing for the tracing. It is easily demonstrated via a few queries that the issue lies in the re-execution. Let's observe:

❯ time curl -X POST -H "Content-Type: application/json" --data '{"method":"debug_traceTransaction","params":["0x52316c4e59d7db74801c8370044eff4a7eb58b79daec81bb9c0e147762cb44ba", { "tracer": "noopTracer", "timeout": "600s" }],"id":1,"jsonrpc":"2.0"}' https://rpc.xinfin.network
{"jsonrpc":"2.0","id":1,"result":{}}
curl -X POST -H "Content-Type: application/json" --data    0.02s user 0.01s system 4% cpu 0.474 total

This re-executes a simple transfer in the middle of the block. Time taken is 0.5s.

The following transaction executes a contract and uses 40k gas:

❯ time curl -X POST -H "Content-Type: application/json" --data '{"method":"debug_traceTransaction","params":["0x7204e1f9339ee3fc9ec7bf75bf077470a2326e6e314f3b5e8222b038d0314db4", { "tracer": "noopTracer", "timeout": "600s" }],"id":1,"jsonrpc":"2.0"}' https://rpc.xinfin.network
{"jsonrpc":"2.0","id":1,"result":{}}
curl -X POST -H "Content-Type: application/json" --data    0.02s user 0.01s system 5% cpu 0.463 total

Again around 0.5s.

Now here's a transaction that's burning more than 6 million gas. First we use the noopTracer which returns after roughly 9s. And callTracer which actually does processing of the data fails with timeout.

❯ time curl -X POST -H "Content-Type: application/json" --data '{"method":"debug_traceTransaction","params":["0x4b5f5dc7c86fdc275fe5466c58ffca3ae6a76eded952a73c6d88b836183fa4a4", { "tracer": "noopTracer", "timeout": "600s" }],"id":1,"jsonrpc":"2.0"}' https://rpc.xinfin.network
{"jsonrpc":"2.0","id":1,"result":{}}
curl -X POST -H "Content-Type: application/json" --data    0.02s user 0.01s system 0% cpu 9.397 total

~ 9s
❯ time curl -X POST -H "Content-Type: application/json" --data '{"method":"debug_traceTransaction","params":["0x4b5f5dc7c86fdc275fe5466c58ffca3ae6a76eded952a73c6d88b836183fa4a4", { "tracer": "callTracer", "timeout": "600s" }],"id":1,"jsonrpc":"2.0"}' https://rpc.xinfin.network
{"error":"http server timeout"}curl -X POST -H "Content-Type: application/json" --data    0.02s user 0.01s system 0% cpu 10.387 total

This tells us tracing bottleneck is (not surprisingly) in execution. To understand that better keep in mind the difference between noopTracer and callTracer used above. They are both Javascript codes that are invoked by the client on various events (most notably opcode execution). The difference is tho that noopTracer does no processing whatsoever. However callTracer actually has JS code to infer the structure of a tx (it's calls and subcalls) from those opcodes. Executing JS code from Go is expensive, hence this takes a long time.

Proposal

As mentioned above the EVM will call into the JS step() function of the callTracer for every opcode executed. When we have 6 million gas, that is potentially a lot of opcodes. This issue has been largely mitigated in upstream go-ethereum:

Improving the JS callTracer

Better JS engine

Upstream go-ethereum has migrated from duktape to Goja as its JS interpretation engine. The large difference is duktape is written via cgo. That means any time a JS code is executed (once per opcode) the runtime has to cross the Go-C barrier. On the other hand, Goja is written in native Go. It performs faster. This is a low-hanging fruit and will result in a 2x improvement. The code for the goja tracer.

OnEnter/OnExit events

callTracer gathers information about all the EVM calls within a transaction. In the current version of XDC, this is done via meticuluosly checking every opcode, seeing if it is a CALL/DELEGATECALL/STATICCALL or CREATE/CREATE2 and marking the beginning of the call. Then on a RETURN or REVERT note the end of that call. However this means this step() function will be processed for every other unrelated opcode such as PUSH* LOG* DUP*, etc. too.

In upstream go-ethereum new event hooks have been added to the EVM to capture calls directly. After adopting them it will be possible to update the JS callTracer to use that information instead of needing to parse that info from the opcodes. This will result in an order of magnitude improvement.

Native tracers FTW

Interpreting JS code from Go is very expensive. Specially that XDC client is still using duktape as its JS engine which has to cross the Go-C barrier as well. Upstream go-ethereum has migrated to a native Go callTracer which is possibly 1-2 orders of magnitude faster. This is definitely the way to go long-term. Here's the code. This would require a larger refactor of the tracing infrastructure.