1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
|
Delivery-date: Tue, 09 Apr 2024 17:28:52 -0700
Received: from mail-yw1-f184.google.com ([209.85.128.184])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBC3PT7FYWAMRBPF226YAMGQE5OJW6KQ@googlegroups.com>)
id 1ruLpb-0008Lq-8A
for bitcoindev@gnusha.org; Tue, 09 Apr 2024 17:28:52 -0700
Received: by mail-yw1-f184.google.com with SMTP id 00721157ae682-60cd62fa1f9sf96298807b3.0
for <bitcoindev@gnusha.org>; Tue, 09 Apr 2024 17:28:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1712708925; x=1713313725; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=pKpxauU65a//Wja4VqYRNZBUERAEInr2nHlYpcie9gw=;
b=uJTvynTASE1BvuhO5cuBzzjcmKV5xsXENjs1sULCUoauHxtJv9zZPzUMPzHXdRcYsW
2HcgrA8vL+PKjPZQjN9RTXS46gqICu8xX4C3++YlnNPedJGdvrSjAZY/O/CLuhNGGWXL
jBBeJBzr1Qh00r0N8sHhZG92FD6svzmg5ZHvO2zLc3MAIEANvLold2UeENPWeFTx4+xd
KsbZ/hGWvd90d1ayFo4lxteOmrWBLoXiGA18cIrsdJIHQYVeeuYti+br0GbnmMAgZd+d
zx1IEm9IX/s4Y74pn9JyQDulJNryMAm6b/QzULL0KrXE1C5/D9rt6RLONp+784drHtH9
BxZg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1712708925; x=1713313725; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:from:to:cc
:subject:date:message-id:reply-to;
bh=pKpxauU65a//Wja4VqYRNZBUERAEInr2nHlYpcie9gw=;
b=mZgd+Q3glR4uF6I4As5vN2Jt9gd2pHizw52km96r9kc7k3TlgEiEsl/LDzh0c06on4
xQVGINQP9sKQRtdb+J86W2qiqwmIymfm9Q9NJNrR2R/tCsDHG0QxXCsPyfM/978OFAiG
WRJu6D96YVu2FlceiF8ZiT5DTFqUvwqW/jb2Vbeja+J/Er0spRJlSZuyAycFz8YD/yQr
W+pM9ZgGfxKoiAnEWZ8pa59wrqxM+IDrDr3pcZtJYVMLcI0Njr4bRKze1Dk/uTNrhiqb
kQqYihRNTWYOlMlsAuPD7i80Tyn73bUA22obZgE4n+37jNrAIXvZ0L8Vl6uEkWsH96t5
rvtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1712708925; x=1713313725;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=pKpxauU65a//Wja4VqYRNZBUERAEInr2nHlYpcie9gw=;
b=iEHWfp8xiTY8AONo6z1YABqosjTlXGe8e6o/qUzHDCEMf5upYTb74u0ZdwgNtogw0L
FsWb3Myh7YMw8Pc/KyqmcvLG4OEGXpxyhvCUhx0SrnSlj5AbLPmdR7SnzxhRz0ZcCggT
2xGyBN67k8qp/AGjg74ocfISc1zIfa4TvuhS+pDqAkwgiaou9rPJJb70ZacWWfkCUkkh
8oHAwgVYWO9n1EX/nioT3S7DW0sIZvu/ajgogNA2c4MWD8mhoswypgGdR8YCp+brQFmL
rWhhahUALICvorQOwkrpzTRFb6r4SXco5EONmQ/QVG7v7L8wFRN5TD7/C4Fk00XeDXXX
C7hg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCW8ARiMn8Ac/aBN/aA0qWy09EsShHAjy0nfaWIH2WYsH1QjtYwOCT0GxRjfPeoQ/+B7nVGqnkMM3i5lMdH3Qq7VqkVzVjc=
X-Gm-Message-State: AOJu0YzHb8mVvCbIerzQVWNBj9335nA8bhZsrUesrPkngd/X0r5yJ+c1
SGDFEHaQ3Oy1ffeScqfWaAKihdN4YwTSNWLNsS5HdkvCWwfnp454
X-Google-Smtp-Source: AGHT+IEXlkyxSisuqm2TfVSlb1PH7MBq+gT3U8WXVNy8YnnYYwQ+KigAfDEiLhWmlbw6rsXavFZrwQ==
X-Received: by 2002:a25:902:0:b0:dc2:3936:5fa5 with SMTP id 2-20020a250902000000b00dc239365fa5mr1292921ybj.51.1712708924981;
Tue, 09 Apr 2024 17:28:44 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:72c4:0:b0:dcc:4b24:c0dd with SMTP id n187-20020a2572c4000000b00dcc4b24c0ddls212239ybc.0.-pod-prod-08-us;
Tue, 09 Apr 2024 17:28:43 -0700 (PDT)
X-Received: by 2002:a25:d312:0:b0:dc6:f877:ea7b with SMTP id e18-20020a25d312000000b00dc6f877ea7bmr334768ybf.9.1712708923746;
Tue, 09 Apr 2024 17:28:43 -0700 (PDT)
Received: by 2002:a05:690c:dc6:b0:609:3e5d:63d0 with SMTP id 00721157ae682-61841304c15ms7b3;
Tue, 9 Apr 2024 16:35:43 -0700 (PDT)
X-Received: by 2002:a25:d312:0:b0:dc6:f877:ea7b with SMTP id e18-20020a25d312000000b00dc6f877ea7bmr309942ybf.9.1712705742541;
Tue, 09 Apr 2024 16:35:42 -0700 (PDT)
Date: Tue, 9 Apr 2024 16:35:42 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <74f23461-fae2-4dd7-9a20-5e6557cd1f2fn@googlegroups.com>
In-Reply-To: <5U7FixH_a7lxjcGGxLi5i-XRPXSVQfMyFHyEfwI532OTI1NoGUkD1s8Is3lEj07bL_1znuiEUwRfd7RNTdsA0kRLcRP1BNBZznHDD3YY0Sw=@notatether.com>
References: <a358aaac-62d5-4d30-a599-40c94da66c4fn@googlegroups.com>
<xXMlG6tjc8Zq-mJ5J6mM8xCqSbzLeJMP6pHmaEsrmkmqXlTLhroNtaPtY16nHq0u5APSMY4F518X22fWSjRBQ_MWpqkfN-jnceZxHsZU14k=@proton.me>
<HKLeYC_TSyA-x9bqKW2ono6zSUV3XpVsu2S1uPMU3NBnXTGHxZ1bLx0K9YztYRK-3kKXsWtz0TCrKsNg5BkvNnNKzX9zwRtl5slNRVsLSzA=@notatether.com>
<5U7FixH_a7lxjcGGxLi5i-XRPXSVQfMyFHyEfwI532OTI1NoGUkD1s8Is3lEj07bL_1znuiEUwRfd7RNTdsA0kRLcRP1BNBZznHDD3YY0Sw=@notatether.com>
Subject: Re: [bitcoindev] Security implications of using pseudorandom JSON-RPC IDs
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_17408_1687740009.1712705742175"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)
------=_Part_17408_1687740009.1712705742175
Content-Type: multipart/alternative;
boundary="----=_Part_17409_1775370888.1712705742175"
------=_Part_17409_1775370888.1712705742175
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Ali,
Bitcoin Core RPC protocol as documented in `src/rpc/protocol` RPCErrorCode=
=20
does not commit to unique JSON RPC IDs towards applications.
About metadata ids, Bitcoin Core's `WorkQueue` only knows about=20
`std::unique_ptr` which is a pointer itself, and as such should have a=20
unique virtual memory address assigned by your kernel to your `bitcoind`=
=20
process. While indeed memory corruption *could* lead to resolve a RPC call=
=20
pointer to another address of a `bitcoind`'s function,
this is dependent on the binary compilation flags, among other things.=20
In the future, if you find memory corruption bugs in Bitcoin Core, even=20
benign in non-significant subsystems, thanks to communicate them with=20
sufficient technical description to security@bitcoincore.org or security=20
reporters you trust. If you don't have experience in security handling=20
disclosure, you can consult=20
https://bitcoinops.org/en/topics/responsible-disclosures/ or=20
Linux's https://docs.kernel.org/process/security-bugs.html#securitybugs
Generally, I'll discourage to have multiple user-level applications sharing=
=20
a common Bitcoin Core JSON-RPC on a single process instance, as soon as you=
=20
have funds at stake, and when it''s not only for informational purpose like=
=20
knowing chain state height (e.g block explorer) or features set available.=
=20
There is no end-to-end encryption of
the JSON RPC calls from user with corresponding key distribution protocol=
=20
for endpoints. See `doc/JSON-RPC-interface.md` for more.
Best,
Antoine
Le dimanche 7 avril 2024 =C3=A0 09:28:26 UTC+1, Ali Sherief a =C3=A9crit :
>
> I think the conversation did not get sent to the mailing list somehow.=20
> Still trying to get the hang of Google Groups I guess. Anyway I'm going t=
o=20
> 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=20
> JSON-RPC IDs
> To: hashnoncemessage <hashnonc...@proton.me>
>
> Using the RPC method 'getrpcinfo', I can't seem to produce a parallel RPC=
=20
> evaluation, even though I am using 4 RPC threads.
>
> If anyone wants to reproduce, you can simulate asynchronous calls in Bash=
=20
> 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=20
> which they get the RPC request from: (
> https://github.com/bitcoin/bitcoin/blob/0f0e36de5f53f82d31416dc05a24d2885=
781ce57/src/httpserver.cpp#L70-L125
> )=20
>
> So as I understand it, the system doesn't actually make use of the=20
> JSON-RPC metadata such as id, but it's just distributing the work in the=
=20
> queue to different threads. So it is not possible to use the id to corrup=
t=20
> the work queue.
>
> However, what I did notice is that the internal evhttp_request variables=
=20
> can (theoretically) be edited to resolve to a different pointer in order =
to=20
> achieve the same effect, of receiving a different JSON reply. This would=
=20
> require some form of memory corruption bug to be found in Bitcoin Core th=
at=20
> affects some global data structure that comes close enough before=20
> g_work_queue or the queue itself, so for linux-gcc on x86 platforms at=20
> least, any of these variables: (
> https://github.com/bitcoin/bitcoin/blob/0f0e36de5f53f82d31416dc05a24d2885=
781ce57/src/httpserver.cpp#L141-L147
> )
>
> But it would be more likely to cause a node crash than the intended=20
> result, I think.
>
> Obviously I'm not a security researcher but I do have a good grasp of C++=
,=20
> so just doing my due diligence to check what kind of attack vectors exist=
=20
> 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)=
=20
> request initiated by the client.=20
>
> Request IDs are used for correlation of different requests from the same=
=20
> client.=20
>
> Core will not send your client=E2=80=99s response to a different=20
> client/connection.=20
>
>
> 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=20
> UniValue JSON-RPC requests.
>
> The reason being is because I have an application that uses pseudorandom=
=20
> IDs for the JSON-RPC calls, and I'm trying to make sure that Core isn't=
=20
> going to send me someone else's JSON-RPC response if somebody else happen=
s=20
> to be making a request with that ID at the same instant, which could be a=
=20
> potential security issue.
>
> So far I don't have any leads on the Github codebase yet, but I'm still=
=20
> looking.
>
> Anyway I would appreciate if someone would clarify this topic for me.
>
> ---
> Ali
>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to bitcoindev+...@googlegroups.com.
> To view this discussion on the web visit=20
> https://groups.google.com/d/msgid/bitcoindev/a358aaac-62d5-4d30-a599-40c9=
4da66c4fn%40googlegroups.com
> .
>
>
>
>
--=20
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 e=
mail 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.
------=_Part_17409_1775370888.1712705742175
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Ali,<div><br /></div><div>Bitcoin Core RPC protocol as documented in `sr=
c/rpc/protocol` RPCErrorCode does not commit to unique JSON RPC IDs towards=
applications.</div><div><br /></div><div>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 k=
ernel to =C2=A0your `bitcoind` process. While indeed memory corruption *cou=
ld* lead to resolve a RPC call pointer to another address of a `bitcoind`'s=
function,</div><div>this is dependent on the binary compilation flags, amo=
ng other things.=C2=A0</div><div><br /></div><div>In the future, if you fin=
d memory corruption bugs in Bitcoin Core, even benign in non-significant su=
bsystems, =C2=A0thanks to communicate them with sufficient technical descri=
ption to=C2=A0security@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=C2=A0h=
ttps://docs.kernel.org/process/security-bugs.html#securitybugs</div><div><b=
r /></div><div>Generally, I'll discourage to have multiple user-level appli=
cations 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 informati=
onal purpose like knowing chain state height (e.g block explorer) or featur=
es set available. There is no end-to-end encryption of</div><div>the JSON R=
PC calls from user with corresponding key distribution protocol for endpoin=
ts. See `doc/JSON-RPC-interface.md` for more.</div><div><br /></div><div>Be=
st,</div><div>Antoine</div><div><br /></div><div class=3D"gmail_quote"><div=
dir=3D"auto" class=3D"gmail_attr">Le dimanche 7 avril 2024 =C3=A0 09:28:26=
UTC+1, Ali Sherief a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204,=
204); padding-left: 1ex;"><div style=3D"font-family:Arial,sans-serif;font-=
size:14px"><br></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
<div>
=20
</div>
=20
<div>
=20
</div>
</div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px"><span>I think th=
e conversation did not get sent to the mailing list somehow. Still trying t=
o get the hang of Google Groups I guess. Anyway I'm going to forward it=
here just to be sure.</span><div><br></div><div><span>---</span></div><spa=
n>Ali</span><br></div><div>
------- Forwarded Message -------<br>
From: Ali Sherief <<a href data-email-masked rel=3D"nofollow">a.=
..@notatether.com</a>><br>
Date: On Sunday, April 7th, 2024 at 7:47 AM<br>
Subject: Re: [bitcoindev] Security implications of using pseudorand=
om JSON-RPC IDs<br>
To: hashnoncemessage <<a href data-email-masked rel=3D"nofollow"=
>hashnonc...@proton.me</a>><br>
<br>
<blockquote type=3D"cite">
<div style=3D"font-family:Arial,sans-serif;font-size:14px;color=
:rgb(0,0,0);background-color:rgb(255,255,255)">Using the RPC method 'ge=
trpcinfo', I can't seem to produce a parallel RPC evaluation, even =
though I am using 4 RPC threads.</div><div style=3D"font-family:Arial,sans-=
serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><b=
r></div><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb=
(0,0,0);background-color:rgb(255,255,255)">If anyone wants to reproduce, yo=
u can simulate asynchronous calls in Bash or another shell:</div><div style=
=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background=
-color:rgb(255,255,255)"><br></div><div style=3D"font-family:Arial,sans-ser=
if;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">bitco=
in-cli getblockchaininfo &</div><div style=3D"font-family:Arial,sans-se=
rif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">bitc=
oin-cli getrpcinfo</div><div style=3D"font-family:Arial,sans-serif;font-siz=
e:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div><div s=
tyle=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);backgr=
ound-color:rgb(255,255,255)">The output of the second command on my machine=
is:</div><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:r=
gb(0,0,0);background-color:rgb(255,255,255)"><br></div><div style=3D"font-f=
amily:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb=
(255,255,255)"><span>{</span><div><span>=C2=A0 "active_commands":=
[</span></div><div><span>=C2=A0 =C2=A0 {</span></div><div><span>=C2=A0 =C2=
=A0 =C2=A0 "method": "getrpcinfo",</span></div><div><sp=
an>=C2=A0 =C2=A0 =C2=A0 "duration": 58</span></div><div><span>=C2=
=A0 =C2=A0 }</span></div><div><span>=C2=A0 ],</span></div><div><span>=C2=A0=
"logpath": "/home/zenulabidin/.bitcoin/debug.log"</spa=
n></div><span>}</span></div><div style=3D"font-family:Arial,sans-serif;font=
-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br>I see th=
at there is a global work queue shared by all the threads from which they g=
et the RPC request from: (<span><a href=3D"https://github.com/bitcoin/bitco=
in/blob/0f0e36de5f53f82d31416dc05a24d2885781ce57/src/httpserver.cpp#L70-L12=
5" rel=3D"noreferrer nofollow noopener" target=3D"_blank" data-saferedirect=
url=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://github.com/bitcoi=
n/bitcoin/blob/0f0e36de5f53f82d31416dc05a24d2885781ce57/src/httpserver.cpp%=
23L70-L125&source=3Dgmail&ust=3D1712785243116000&usg=3DAOvVaw1L=
e0tR1OHYOOxpQW-M5Dkg">https://github.com/bitcoin/bitcoin/blob/0f0e36de5f53f=
82d31416dc05a24d2885781ce57/src/httpserver.cpp#L70-L125</a>)=C2=A0</span></=
div><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0=
,0);background-color:rgb(255,255,255)"><span><br></span></div><div style=3D=
"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-co=
lor:rgb(255,255,255)"><span>So as I understand it, the system doesn't a=
ctually make use of the JSON-RPC metadata such as id, but it's just dis=
tributing the work in the queue to different threads. So it is not possible=
to use the id to corrupt the work queue.</span></div><div style=3D"font-fa=
mily:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(=
255,255,255)"><span><br></span></div><div style=3D"font-family:Arial,sans-s=
erif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><sp=
an>However, what I did notice is that the internal evhttp_request variables=
can (theoretically) be edited to resolve to a different pointer in order t=
o 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_q=
ueue or the queue itself, so for linux-gcc on x86 platforms at least, any o=
f these variables: (<span><a href=3D"https://github.com/bitcoin/bitcoin/blo=
b/0f0e36de5f53f82d31416dc05a24d2885781ce57/src/httpserver.cpp#L141-L147" re=
l=3D"noreferrer nofollow noopener" target=3D"_blank" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://github.com/bitcoin/b=
itcoin/blob/0f0e36de5f53f82d31416dc05a24d2885781ce57/src/httpserver.cpp%23L=
141-L147&source=3Dgmail&ust=3D1712785243116000&usg=3DAOvVaw1jH9=
9bx52Ow51NVTk4T1gV">https://github.com/bitcoin/bitcoin/blob/0f0e36de5f53f82=
d31416dc05a24d2885781ce57/src/httpserver.cpp#L141-L147</a>)</span></span></=
div><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0=
,0);background-color:rgb(255,255,255)"><span><span><br></span></span></div>=
<div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);=
background-color:rgb(255,255,255)"><span><span>But it would be more likely =
to cause a node crash than the intended result, I think.</span></span></div=
><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0)=
;background-color:rgb(255,255,255)"><span><span><br></span></span></div><di=
v style=3D"background-color:rgb(255,255,255)"><font face=3D"Arial, sans-ser=
if">Obviously I'm not a security researcher but I do have a good grasp =
of C++, so just doing my due diligence=C2=A0to check what kind of attack ve=
ctors exist in my program's dependencies.</font></div><div style=3D"bac=
kground-color:rgb(255,255,255)"><font face=3D"Arial, sans-serif"><br></font=
></div><div style=3D"background-color:rgb(255,255,255)"><font face=3D"Arial=
, sans-serif">---</font></div><div style=3D"background-color:rgb(255,255,25=
5)"><font face=3D"Arial, sans-serif">Ali</font></div><div style=3D"font-fam=
ily:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(2=
55,255,255)"><br></div><div>
On Sunday, April 7th, 2024 at 6:33 AM, hashnoncemessage <<a href=
data-email-masked rel=3D"nofollow">hashnonc...@proton.me</a>> wrote:<br=
>
<blockquote type=3D"cite">
<div dir=3D"auto">As I understand it, the json rpc server re=
sponds directly to the (http) request initiated by the client.=C2=A0</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Request IDs are used for corre=
lation of different requests from the same client.=C2=A0</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Core will not send your client=E2=80=99s r=
esponse to a different client/connection.=C2=A0</div></blockquote></div></b=
lockquote></div><div><blockquote type=3D"cite"><div><blockquote type=3D"cit=
e"><div dir=3D"auto"><br></div>On Sun, Apr 7, 2024 at 07:57, Ali Sherief &l=
t;<a href rel=3D"noreferrer nofollow noopener" data-email-masked>a...@notat=
ether.com</a>> wrote:</blockquote></div></blockquote></div><div><blockqu=
ote type=3D"cite"><div><blockquote type=3D"cite"><blockquote type=3D"cite">=
I am trying to figure out how the Bitcoin Core RPC server stores the UniV=
alue JSON-RPC requests.<div><br></div><div>The reason being is because I ha=
ve an application that uses pseudorandom IDs for the JSON-RPC calls, and I&=
#39;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 wi=
th that ID at the same instant, which could be a potential security issue.<=
/div><div><br></div><div>So far I don't have any leads on the Github co=
debase yet, but I'm still looking.</div><div><br></div><div>Anyway I wo=
uld appreciate if someone would clarify this topic for me.</div><div><br></=
div><div>---</div><div>Ali</div>
<p></p></blockquote></blockquote></div></blockquote></div><div><blockquote =
type=3D"cite"><div><blockquote type=3D"cite"><blockquote type=3D"cite">
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href rel=3D"noreferrer nofollow noopener" data-email-masked>bitc=
oindev+...@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/a358aaac-62d5-4d30-a599-40c94da66c4fn%40googlegroups.=
com" rel=3D"noreferrer nofollow noopener" target=3D"_blank" data-saferedire=
cturl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://groups.google.c=
om/d/msgid/bitcoindev/a358aaac-62d5-4d30-a599-40c94da66c4fn%2540googlegroup=
s.com&source=3Dgmail&ust=3D1712785243116000&usg=3DAOvVaw3cdnTJW=
xpGmTnfW7roCIaF">https://groups.google.com/d/msgid/bitcoindev/a358aaac-62d5=
-4d30-a599-40c94da66c4fn%40googlegroups.com</a>.<br>
</blockquote>
</blockquote><br>
</div>
</blockquote><br>
</div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/74f23461-fae2-4dd7-9a20-5e6557cd1f2fn%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/74f23461-fae2-4dd7-9a20-5e6557cd1f2fn%40googlegroups.com</a>.=
<br />
------=_Part_17409_1775370888.1712705742175--
------=_Part_17408_1687740009.1712705742175--
|