I think the conversation did not get sent to the mailing list somehow. Still trying to get the hang of Google Groups I guess. Anyway I'm going to forward it here just to be sure.

---
Ali
------- Forwarded Message -------
From: Ali Sherief <ali@notatether.com>
Date: On Sunday, April 7th, 2024 at 7:47 AM
Subject: Re: [bitcoindev] Security implications of using pseudorandom JSON-RPC IDs
To: hashnoncemessage <hashnoncemessage@proton.me>

Using the RPC method 'getrpcinfo', I can't seem to produce a parallel RPC evaluation, even though I am using 4 RPC threads.

If anyone wants to reproduce, you can simulate asynchronous calls in Bash or another shell:

bitcoin-cli getblockchaininfo &
bitcoin-cli getrpcinfo

The output of the second command on my machine is:

{
  "active_commands": [
    {
      "method": "getrpcinfo",
      "duration": 58
    }
  ],
  "logpath": "/home/zenulabidin/.bitcoin/debug.log"
}

I see that there is a global work queue shared by all the threads from which they get the RPC request from: (https://github.com/bitcoin/bitcoin/blob/0f0e36de5f53f82d31416dc05a24d2885781ce57/src/httpserver.cpp#L70-L125

So as I understand it, the system doesn't actually make use of the JSON-RPC metadata such as id, but it's just distributing the work in the queue to different threads. So it is not possible to use the id to corrupt the work queue.

However, what I did notice is that the internal evhttp_request variables can (theoretically) be edited to resolve to a different pointer in order to achieve the same effect, of receiving a different JSON reply. This would require some form of memory corruption bug to be found in Bitcoin Core that affects some global data structure that comes close enough before g_work_queue or the queue itself, so for linux-gcc on x86 platforms at least, any of these variables: (https://github.com/bitcoin/bitcoin/blob/0f0e36de5f53f82d31416dc05a24d2885781ce57/src/httpserver.cpp#L141-L147)

But it would be more likely to cause a node crash than the intended result, I think.

Obviously I'm not a security researcher but I do have a good grasp of C++, so just doing my due diligence to check what kind of attack vectors exist in my program's dependencies.

---
Ali

On Sunday, April 7th, 2024 at 6:33 AM, hashnoncemessage <hashnoncemessage@proton.me> wrote:
As I understand it, the json rpc server responds directly to the (http) request initiated by the client. 

Request IDs are used for correlation of different requests from the same client. 

Core will not send your client’s response to a different client/connection. 

On Sun, Apr 7, 2024 at 07:57, Ali Sherief <ali@notatether.com> wrote:
I am trying to figure out how the Bitcoin Core RPC server stores the UniValue JSON-RPC requests.

The reason being is because I have an application that uses pseudorandom IDs for the JSON-RPC calls, and I'm trying to make sure that Core isn't going to send me someone else's JSON-RPC response if somebody else happens to be making a request with that ID at the same instant, which could be a potential security issue.

So far I don't have any leads on the Github codebase yet, but I'm still looking.

Anyway I would appreciate if someone would clarify this topic for me.

---
Ali

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/a358aaac-62d5-4d30-a599-40c94da66c4fn%40googlegroups.com.


--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/5U7FixH_a7lxjcGGxLi5i-XRPXSVQfMyFHyEfwI532OTI1NoGUkD1s8Is3lEj07bL_1znuiEUwRfd7RNTdsA0kRLcRP1BNBZznHDD3YY0Sw%3D%40notatether.com.