Description
The rpc endpoint /getrandomrctouts.bin takes a uint64 outscount as input and will return that many random outputs:
https://github.com/monero-project/monero/blob/9315e12d34a58970b311133f98f2b3e651f0ceb3/src/rpc/core_rpc_server.cpp#L479
There is no sanitization of the req.outs_count input in this function. (Other similar functions make sure the client does not request too many outputs at once).
The function then calls into Blockchain::getrandomrctouts to get the outputs, again with no checking of the range of req.outscount:
https://github.com/monero-project/monero/blob/master/src/cryptonote_core/blockchain.cpp#L1848
A naive hacker could send something like MAX_UINT64 and this function will send back all valid outputs. As of testing, this was around 6mm outs and resulted in a response of around 500MB. This in itself is a nuisance, as it ties up the thread, pegs the cpu to 100%, and has to allocate a GB or so of memory. But the rpc will eventually complete in such a case.
A better attacker could take advantage of the triangular distribution applied to the random number generator:
https://github.com/monero-project/monero/blob/master/src/cryptonote_core/blockchain.cpp#L1900
This math makes it very unlikely to land on very low txn indexes. For example, based on some empirical evidence, in order to get the 0th index, the random number (mod 2^53) would need to be in the range [0-205]. If my math is right, the probability of landing on the 0th index would be roughly (2^8/2^53 + 2^8/2^11), which is extremely unlikely.
This function loops until it finds outscount random txns. If an attacker sends an outscount equal to (or very close to) the total valid outputs, it will attempt to loop until it randomly chooses all/most unique values between [0-num_outs), which will most likely never complete since the triangular distribution makes it extremely unlikely to land on the low indexes.
Vector: BVSS:1.1/B:N/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H/CI:N/II:H/AI:N