CVE-2021-46102: New Integer Overflow Bug Discovered in Solana rBPF - BlockSecTeam - Medium

Recently, our vulnerability detection system discovered a critical issue in the rBPF of Solana (i.e., the virtual machine where all the Solana dApps are running on: https://github.com/solana-labs/rbpf). After a careful investigation, we found that it is an integer overflow bug which can be exploited to crash down the whole Solana network. We have reported the bug to the Solana security team, and the team immediately sprang into action to confirm and fix the bug. As of this writing, almost all the validator nodes received the patch and upgraded to the latest version, which means it is safe to make a public disclosure.

eBPF and rBPF

Extended Berkeley Packet Filter (eBPF[1]) is initially developed for filtering packets in the kernel. Due to the security, efficiency, and scalability of eBPF, it is now used in various areas like networking, tracing, profiling, etc[2]. Considering the rich capability of eBPF, Solana choose it as the execution engine for the smart contract as well. To build the dApps on Solana, developers need to develop their smart contracts in Rust that will be compiled into eBPF bytecode.

To host the dApps of Solana, a precise virtual machine for eBPF is required. In this case, Solana uses the rBPF, which is a virtual machine for eBPF written in Rust. However, whether the proposed virtual machine (i.e., rBPF) is robust, secure, and precise is unknown. Once there exist security issues inside the rBPF, all the validators containing the rBPF can be influenced, resulting in huge loss (e.g., DDoS attack) for the whole Solana network.

The root cause of the bug

We have developed a tool to locate the bugs for the rBPF. This tool is still under the active development. During this process, one serious problem was identified in rBPF (version 0.2.16), which can take down the whole network.

Specifically, function “load” in file “elf.rs” is used to parse and verify the ELF file (the smart contract). First, function “load” would read the ELF structure and invoke function “relocate” to set up the callee offset. However, in function “relocate”, the attribute “sym.st_value” is retrieved from the ELF file directly (https://github.com/solana-labs/rbpf/blob/c14764850f0b83b58aa013248eaf6d65836c1218/src/elf.rs#L609-L630). If the “st_value” is large enough, integer overflow could be triggered when calculating the “addr”, which is the sum-up of “sym.st_value” and “refd_pa”.

In this case, an attacker can create a malicious ELF file as a smart contract, which can trigger the integer overflow. After that, every validator would run the target ELF file and the rBPF would get panic with “add with overflow”.

At this moment, rBPF will get stuck and the coming transactions will not be executed, resulting in a DoS attack. We can observe that the node get stuck at “Finalizing transaction”, which is shown in the following, due to the integer overflow while loading the ELF file.

This issue was introduced in https://github.com/solana-labs/rbpf/pull/200, meaning the rBPF is vulnerable from version 0.2.14. We identified the issue and reported it to the Solana security team on 2021 December 6th. Solana fixes the issue in a few hours by using the safemath mechanism after our report. The fix is in https://github.com/solana-labs/rbpf/pull/236. At the time of writing (2021/12/30), more than 86% of the validators have upgraded to the newest version.

[1] https://en.wikipedia.org/wiki/Berkeley_Packet_Filter

[2] https://ebpf.io/

Timeline

• 2021/12/06: the problem was reported to the Solana security team
• 2021/12/06: the vulnerability was fixed.
• 2021/12/30: the information of this vulnerability was released