* [bitcoindev] Security implications of using pseudorandom JSON-RPC IDs
@ 2024-04-07 5:57 Ali Sherief
[not found] ` <xXMlG6tjc8Zq-mJ5J6mM8xCqSbzLeJMP6pHmaEsrmkmqXlTLhroNtaPtY16nHq0u5APSMY4F518X22fWSjRBQ_MWpqkfN-jnceZxHsZU14k=@proton.me>
0 siblings, 1 reply; 3+ messages in thread
From: Ali Sherief @ 2024-04-07 5:57 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 975 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 1346 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread[parent not found: <xXMlG6tjc8Zq-mJ5J6mM8xCqSbzLeJMP6pHmaEsrmkmqXlTLhroNtaPtY16nHq0u5APSMY4F518X22fWSjRBQ_MWpqkfN-jnceZxHsZU14k=@proton.me>]
[parent not found: <HKLeYC_TSyA-x9bqKW2ono6zSUV3XpVsu2S1uPMU3NBnXTGHxZ1bLx0K9YztYRK-3kKXsWtz0TCrKsNg5BkvNnNKzX9zwRtl5slNRVsLSzA=@notatether.com>]
* Re: [bitcoindev] Security implications of using pseudorandom JSON-RPC IDs [not found] ` <HKLeYC_TSyA-x9bqKW2ono6zSUV3XpVsu2S1uPMU3NBnXTGHxZ1bLx0K9YztYRK-3kKXsWtz0TCrKsNg5BkvNnNKzX9zwRtl5slNRVsLSzA=@notatether.com> @ 2024-04-07 8:03 ` Ali Sherief 2024-04-09 23:35 ` Antoine Riard 0 siblings, 1 reply; 3+ messages in thread From: Ali Sherief @ 2024-04-07 8:03 UTC (permalink / raw) To: bitcoindev [-- Attachment #1: Type: text/plain, Size: 4311 bytes --] 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](mailto:On Sun, Apr 7, 2024 at 07:57, Ali Sherief <<a href=)> 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. [-- Attachment #2: Type: text/html, Size: 9759 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoindev] Security implications of using pseudorandom JSON-RPC IDs 2024-04-07 8:03 ` Ali Sherief @ 2024-04-09 23:35 ` Antoine Riard 0 siblings, 0 replies; 3+ messages in thread From: Antoine Riard @ 2024-04-09 23:35 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 5952 bytes --] Hi Ali, Bitcoin Core RPC protocol as documented in `src/rpc/protocol` RPCErrorCode does not commit to unique JSON RPC IDs towards applications. About metadata ids, Bitcoin Core's `WorkQueue` only knows about `std::unique_ptr` which is a pointer itself, and as such should have a unique virtual memory address assigned by your kernel to your `bitcoind` process. While indeed memory corruption *could* lead to resolve a RPC call pointer to another address of a `bitcoind`'s function, this is dependent on the binary compilation flags, among other things. In the future, if you find memory corruption bugs in Bitcoin Core, even benign in non-significant subsystems, thanks to communicate them with sufficient technical description to security@bitcoincore•org or security reporters you trust. If you don't have experience in security handling disclosure, you can consult https://bitcoinops.org/en/topics/responsible-disclosures/ or Linux's https://docs.kernel.org/process/security-bugs.html#securitybugs Generally, I'll discourage to have multiple user-level applications sharing a common Bitcoin Core JSON-RPC on a single process instance, as soon as you have funds at stake, and when it''s not only for informational purpose like knowing chain state height (e.g block explorer) or features set available. There is no end-to-end encryption of the JSON RPC calls from user with corresponding key distribution protocol for endpoints. See `doc/JSON-RPC-interface.md` for more. Best, Antoine Le dimanche 7 avril 2024 à 09:28:26 UTC+1, Ali Sherief a écrit : > > 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 <a...@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 <hashnonc...@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 < > hashnonc...@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 <a...@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+...@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/74f23461-fae2-4dd7-9a20-5e6557cd1f2fn%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 12081 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-04-10 0:28 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-07 5:57 [bitcoindev] Security implications of using pseudorandom JSON-RPC IDs Ali Sherief
[not found] ` <xXMlG6tjc8Zq-mJ5J6mM8xCqSbzLeJMP6pHmaEsrmkmqXlTLhroNtaPtY16nHq0u5APSMY4F518X22fWSjRBQ_MWpqkfN-jnceZxHsZU14k=@proton.me>
[not found] ` <HKLeYC_TSyA-x9bqKW2ono6zSUV3XpVsu2S1uPMU3NBnXTGHxZ1bLx0K9YztYRK-3kKXsWtz0TCrKsNg5BkvNnNKzX9zwRtl5slNRVsLSzA=@notatether.com>
2024-04-07 8:03 ` Ali Sherief
2024-04-09 23:35 ` Antoine Riard
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox