summaryrefslogtreecommitdiff
path: root/0c/ee1bb15ee47241e96418a979420a482bee314a
blob: b9583384f1b230ab1b8d0dcbc6564a77f68ecbad (plain)
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
Delivery-date: Sun, 07 Apr 2024 01:28:33 -0700
Received: from mail-qv1-f55.google.com ([209.85.219.55])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCQ6HM7U3YGRBKNSZGYAMGQEHFVOVDY@googlegroups.com>)
	id 1rtNtB-0008He-17
	for bitcoindev@gnusha.org; Sun, 07 Apr 2024 01:28:33 -0700
Received: by mail-qv1-f55.google.com with SMTP id 6a1803df08f44-69942c6d975sf23848706d6.1
        for <bitcoindev@gnusha.org>; Sun, 07 Apr 2024 01:28:32 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1712478507; cv=pass;
        d=google.com; s=arc-20160816;
        b=fUSdZ8RTP1lBKbntEF3hEZftvo5Ji+8+tJqmXRXPCS5mdPWkLRskD1TQ+iUPC+Ajwz
         rkLghl1e6DVZRMcLWRZd61HRWfq/+A3w/yAjnkPouMsXqWWFOMwfWABkbVeeSIyXnkDU
         knB6N5pM7hGq32SAiT674XjZYwbPHQWV63R9eHCDdmPsK4V5ULwaxKYRVib3k8zt/gxL
         XPzXnwudcxtPtWuAYua2fi6dD86MMVKcGGIGv0gF/UbRIE2IZixFbw01tLpAJT7ZiySI
         Tuolf4GZYjesxoLcT3asvw+YFX3Fw+jXPnW1G3e7sW6CBLufevsCxmoQon5dtrJlAGP/
         JBmA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:mime-version:feedback-id:references
         :in-reply-to:message-id:subject:from:to:date:sender:dkim-signature;
        bh=kxJvkv7EvypSQq7uLi2rkco8JKnsn9b+YfA1HvMxSJI=;
        fh=m6zu02Ljpqd3gBz6pCFxe5SiP4hBngkQUAoEy1fO0u0=;
        b=aUxTlI8ydE2Cma3B6FPW0xA211VG9qvNUWpH9EHjr5VQFlWgVa1dRoEHIOwGBOjwmk
         wcKYxV81JQH9dyjGkLM8TXyuX0/VtgsI7HfSkeUeDOXtWS8O23M+3xZAlMsw5JCnBl5B
         9C0PnoI9gq+8+XlUogydm5fUNXH9N/AZRsanVOjkTrn5z2XxrxgSFiIpE/uh10/m6Hhi
         AP4nEhg4ogtz3NqaSNBzBLu23MTlngtjrrTZcnXz6mjgPzMHwvpnd43OWIJ9Uvi+4OBL
         zGNR8uEx5nYh0JFh0OtDm6XfjEpiGz//FP/auJ0mrr4SZQQ1dCU1lqWBHw6UMaM09WJa
         XHzA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@notatether.com header.s=protonmail header.b=AUQJnBBy;
       spf=pass (google.com: domain of ali@notatether.com designates 185.70.40.22 as permitted sender) smtp.mailfrom=ali@notatether.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=notatether.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1712478507; x=1713083307; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:mime-version:feedback-id:references:in-reply-to
         :message-id:subject:from:to:date:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kxJvkv7EvypSQq7uLi2rkco8JKnsn9b+YfA1HvMxSJI=;
        b=QReFe9WOHpke8CHGz7p70+/TGgxitcQtA4lUlHoXhrvrcGXCLej7w6lNkZlPSoir/b
         QOoNdPcJk9wZdIR99v2Zk9A7QLcCU2jKfsuJxhOHnmMyWrMOdNylFGJlI20DzGjObHNe
         mks3BRvndtD3eI4iJ66oami+BY7kHn0FR1GFDFZ/99uOHOO548dUMoFOkfh+E/A4jG4B
         UijPUWwklnfjWkuVGyDGyq4E3LhSAYGN+NyCF0GUZaGrNpfk/qkol8l4BOVEWOkyGOiI
         ZLi+B5uCW+c6s5IMI14w02nwrLq3FRnmJ7XayQEdLVEkFkLV62ftLQnT/Y+oCoP7vp1V
         VxlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1712478507; x=1713083307;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:mime-version:feedback-id:references:in-reply-to
         :message-id:subject:from:to:date:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=kxJvkv7EvypSQq7uLi2rkco8JKnsn9b+YfA1HvMxSJI=;
        b=sxvVPqzjUpNQYif/FzujY4YM2nHFqxiYFmdTIe44z+l/HPtd0FZqQxdazP8Otr2GCh
         CtiON4jUXpdLa+0LNufbEFbXXI/tgUUxoZlIMaohJzcADlFXG4DqbxRGAKryh4fsWaMD
         np8D74x4VfR0oHiBq4JzRyOGNGVY1dVGKQvhQhC7iLcSoy4GYrjUEq4L+Fml8LfgsfXP
         uKvRHGyyWLjnis/63c3g0wQb6CZ+Uscho7VQxRNVcRhU++RpPh0OhCfK9NuWOvAE1onu
         LHEpT1UO3+B4a4Evv8kB6CeXmBFUgjAodBQdVuEPHwvrjTu1ybcxu8E9r69Cj6m/bgGN
         wC4w==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVSDzjGMzqUCzez50kPNbbZvzXOYiIeROYjYn6W8TS0G9H5TKlGWrKjq3kPGxcCaOQ8YWHaBKP0V3bBbg8IOGiHV3mrhDo=
X-Gm-Message-State: AOJu0YyUDNoxZ+DjkSr1rOJV2F9TvFz4l/qcjAeD8lNkN6TpaTBSlzMX
	v68DaqeLVNQJcVv6sDNUNL+58KfWCoqjiwd7Jf4MHjuZJyYgdyBT
X-Google-Smtp-Source: AGHT+IGgxn9JMNfipg4oeun8y2nTzxbzGWpQ9bkZ41voroyttbK4I5VyL0TqyUs2sjSiJEzYr6bHtA==
X-Received: by 2002:ad4:5d41:0:b0:699:3a91:e25 with SMTP id jk1-20020ad45d41000000b006993a910e25mr9080819qvb.11.1712478506662;
        Sun, 07 Apr 2024 01:28:26 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6214:c2e:b0:690:c63c:5eaa with SMTP id
 a14-20020a0562140c2e00b00690c63c5eaals4122123qvd.0.-pod-prod-03-us; Sun, 07
 Apr 2024 01:28:25 -0700 (PDT)
X-Received: by 2002:a05:6214:3c8e:b0:699:2443:bcee with SMTP id ok14-20020a0562143c8e00b006992443bceemr144354qvb.5.1712478505642;
        Sun, 07 Apr 2024 01:28:25 -0700 (PDT)
Received: by 2002:a05:620a:2988:b0:78d:475c:41d0 with SMTP id af79cd13be357-78d475c421ems85a;
        Sun, 7 Apr 2024 01:03:58 -0700 (PDT)
X-Received: by 2002:a2e:b61b:0:b0:2d8:70a6:9575 with SMTP id r27-20020a2eb61b000000b002d870a69575mr2739908ljn.7.1712477036616;
        Sun, 07 Apr 2024 01:03:56 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1712477036; cv=none;
        d=google.com; s=arc-20160816;
        b=vpxBq4LJZQ8sl+MFRXanVgUpE6K6UPq5u1cEp/JJlfYyrHzijq0L+GVgXAE7C6GlIS
         HdeMn5ZVhc+DJ/e/Ah5sHRPftSumlS4LiGChBt7iModdbrijGEIBUQZ40qr2TI5D4e/E
         naJPxjorvNEgOHiNlio5xNHeAUnmmzdyVEQDPufVsZRI86VwUT6nvwYVdEOXLxW5c65A
         wMzXkstX4LS1P7Ehw3BxluxEZmroBPqhZLd2F2xifIdPI/jm5xK2kdZbKlYqdEORWtms
         7iMwfq4YUgOn58WhieqqWedBfPAoW4SfZOmPx8ZvWHLb+ge91YAMEvw6MQwQBtAP3VDL
         e/ZQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=mime-version:feedback-id:references:in-reply-to:message-id:subject
         :from:to:date:dkim-signature;
        bh=AzvAaiW3ZadcGxACHbsI+wQXRX0A0ZW6EWwzwwZyUTM=;
        fh=lhFSo2W/mHC0QoJ9oNg3A35n0DTltt3CQl1/0RggJlk=;
        b=0j7w4NBShwkUW0tM/0eApOjdjZ9+VyO210DGvJKaH4rl14wWppxg/Q3ketcKrP2xug
         OSVtPDzGCNgtSirFeNIq9G+IsMX5cth1o5MRCPbwPbEPmyLz2KyRhE8JP8y4WHk4SMBV
         b3jARTWktGqfFuDB8QPpmVhwlPRcMDZqJlptX7zJXWEoDGrOev+UKe6doG4mjfsNtWGx
         WToc6gAHLEDbbWwmtnOlmk9wDL0MfB+9x0TN5nX49Ruh4Vh/vP/V+uyCyZOQDBYAVaEB
         lqrpjNEQzG7Qlst2kbRi5f7yswrw0W2rAMYgdB2RANjVKwhqgqkBEyKjQBOPrLoa8q9w
         waRQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@notatether.com header.s=protonmail header.b=AUQJnBBy;
       spf=pass (google.com: domain of ali@notatether.com designates 185.70.40.22 as permitted sender) smtp.mailfrom=ali@notatether.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=notatether.com
Received: from mail-4022.proton.ch (mail-4022.proton.ch. [185.70.40.22])
        by gmr-mx.google.com with ESMTPS id n23-20020a05600c3b9700b004166a35d7e4si265wms.1.2024.04.07.01.03.56
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sun, 07 Apr 2024 01:03:56 -0700 (PDT)
Received-SPF: pass (google.com: domain of ali@notatether.com designates 185.70.40.22 as permitted sender) client-ip=185.70.40.22;
Date: Sun, 07 Apr 2024 08:03:52 +0000
To: "bitcoindev@googlegroups.com" <bitcoindev@googlegroups.com>
From: Ali Sherief <ali@notatether.com>
Subject: Re: [bitcoindev] Security implications of using pseudorandom JSON-RPC IDs
Message-ID: <5U7FixH_a7lxjcGGxLi5i-XRPXSVQfMyFHyEfwI532OTI1NoGUkD1s8Is3lEj07bL_1znuiEUwRfd7RNTdsA0kRLcRP1BNBZznHDD3YY0Sw=@notatether.com>
In-Reply-To: <HKLeYC_TSyA-x9bqKW2ono6zSUV3XpVsu2S1uPMU3NBnXTGHxZ1bLx0K9YztYRK-3kKXsWtz0TCrKsNg5BkvNnNKzX9zwRtl5slNRVsLSzA=@notatether.com>
References: <a358aaac-62d5-4d30-a599-40c94da66c4fn@googlegroups.com> <xXMlG6tjc8Zq-mJ5J6mM8xCqSbzLeJMP6pHmaEsrmkmqXlTLhroNtaPtY16nHq0u5APSMY4F518X22fWSjRBQ_MWpqkfN-jnceZxHsZU14k=@proton.me> <HKLeYC_TSyA-x9bqKW2ono6zSUV3XpVsu2S1uPMU3NBnXTGHxZ1bLx0K9YztYRK-3kKXsWtz0TCrKsNg5BkvNnNKzX9zwRtl5slNRVsLSzA=@notatether.com>
Feedback-ID: 34210769:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1_dz10CEF07ZpdMXeDwRZ6FMRamKxfAOMlSbx367YKGE"
X-Original-Sender: ali@notatether.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@notatether.com header.s=protonmail header.b=AUQJnBBy;
       spf=pass (google.com: domain of ali@notatether.com designates
 185.70.40.22 as permitted sender) smtp.mailfrom=ali@notatether.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=notatether.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.7 (/)

This is a multi-part message in MIME format.

--b1_dz10CEF07ZpdMXeDwRZ6FMRamKxfAOMlSbx367YKGE
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think the conversation did not get sent to the mailing list somehow. Stil=
l trying to get the hang of Google Groups I guess. Anyway I'm going to forw=
ard 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 wh=
ich 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-R=
PC 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 r=
equire 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_qu=
eue or the queue itself, so for linux-gcc on x86 platforms at least, any of=
 these variables: (https://github.com/bitcoin/bitcoin/blob/0f0e36de5f53f82d=
31416dc05a24d2885781ce57/src/httpserver.cpp#L141-L147)
>
> But it would be more likely to cause a node crash than the intended resul=
t, 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=E2=80=99s response to a different client/=
connection.
>>
>> On Sun, Apr 7, 2024 at 07:57, Ali Sherief <[ali@notatether.com](mailto:O=
n Sun, Apr 7, 2024 at 07:57, Ali Sherief <<a href=3D)> wrote:
>>
>>> I am trying to figure out how the Bitcoin Core RPC server stores the Un=
iValue JSON-RPC requests.
>>>
>>> The reason being is because I have an application that uses pseudorando=
m IDs for the JSON-RPC calls, and I'm trying to make sure that Core isn't g=
oing to send me someone else's JSON-RPC response if somebody else happens t=
o be making a request with that ID at the same instant, which could be a po=
tential 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 Grou=
ps "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/ms=
gid/bitcoindev/a358aaac-62d5-4d30-a599-40c94da66c4fn%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/5U7FixH_a7lxjcGGxLi5i-XRPXSVQfMyFHyEfwI532OTI1NoGUkD1s8Is3lEj07b=
L_1znuiEUwRfd7RNTdsA0kRLcRP1BNBZznHDD3YY0Sw%3D%40notatether.com.

--b1_dz10CEF07ZpdMXeDwRZ6FMRamKxfAOMlSbx367YKGE
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div>
<div class=3D"protonmail_signature_block protonmail_signature_block-empty" =
style=3D"font-family: Arial, sans-serif; font-size: 14px;">
    <div class=3D"protonmail_signature_block-user protonmail_signature_bloc=
k-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton protonmail_sign=
ature_block-empty">
       =20
            </div>
</div>
<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><span>I thi=
nk the conversation did not get sent to the mailing list somehow. Still try=
ing to get the hang of Google Groups I guess. Anyway I'm going to forward i=
t here just to be sure.</span><div><br></div><div><span>---</span></div><sp=
an>Ali</span><br></div><div class=3D"protonmail_quote">
        ------- Forwarded Message -------<br>
        From: Ali Sherief &lt;ali@notatether.com&gt;<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 &lt;hashnoncemessage@proton.me&gt;<br>
        <br>
        <blockquote class=3D"protonmail_quote" 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 m=
ethod 'getrpcinfo', 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, sa=
ns-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, =
255, 255);"><br></div><div style=3D"font-family: Arial, sans-serif; font-si=
ze: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">If an=
yone wants to reproduce, you can simulate asynchronous calls in Bash or ano=
ther shell:</div><div style=3D"font-family: Arial, sans-serif; font-size: 1=
4px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div>=
<div style=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0=
, 0, 0); background-color: rgb(255, 255, 255);">bitcoin-cli getblockchainin=
fo &amp;</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px=
; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">bitcoin-cli g=
etrpcinfo</div><div style=3D"font-family: Arial, sans-serif; font-size: 14p=
x; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div><d=
iv style=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, =
0, 0); background-color: rgb(255, 255, 255);">The output of the second comm=
and on my machine is:</div><div style=3D"font-family: Arial, sans-serif; fo=
nt-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">=
<br></div><div style=3D"font-family: Arial, sans-serif; font-size: 14px; co=
lor: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><span>{</span><di=
v><span>&nbsp; "active_commands": [</span></div><div><span>&nbsp; &nbsp; {<=
/span></div><div><span>&nbsp; &nbsp; &nbsp; "method": "getrpcinfo",</span><=
/div><div><span>&nbsp; &nbsp; &nbsp; "duration": 58</span></div><div><span>=
&nbsp; &nbsp; }</span></div><div><span>&nbsp; ],</span></div><div><span>&nb=
sp; "logpath": "/home/zenulabidin/.bitcoin/debug.log"</span></div><span>}</=
span></div><div style=3D"font-family: Arial, sans-serif; font-size: 14px; c=
olor: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br>I see that t=
here is a global work queue shared by all the threads from which they get t=
he RPC request from: (<span><a href=3D"https://github.com/bitcoin/bitcoin/b=
lob/0f0e36de5f53f82d31416dc05a24d2885781ce57/src/httpserver.cpp#L70-L125" r=
el=3D"noreferrer nofollow noopener" target=3D"_blank">https://github.com/bi=
tcoin/bitcoin/blob/0f0e36de5f53f82d31416dc05a24d2885781ce57/src/httpserver.=
cpp#L70-L125</a>)&nbsp;</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-seri=
f; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 25=
5);"><span>So as I understand it, the system doesn't actually make use of t=
he 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.</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-color: rgb(255, 255, 255);"><s=
pan>However, what I did notice is that the internal evhttp_request variable=
s 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 tha=
t 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: (<span><a href=3D"https://github.com/bitcoin/bitcoin/bl=
ob/0f0e36de5f53f82d31416dc05a24d2885781ce57/src/httpserver.cpp#L141-L147" r=
el=3D"noreferrer nofollow noopener" target=3D"_blank">https://github.com/bi=
tcoin/bitcoin/blob/0f0e36de5f53f82d31416dc05a24d2885781ce57/src/httpserver.=
cpp#L141-L147</a>)</span></span></div><div style=3D"font-family: Arial, san=
s-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 2=
55, 255);"><span><span><br></span></span></div><div style=3D"font-family: A=
rial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: r=
gb(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); backg=
round-color: rgb(255, 255, 255);"><span><span><br></span></span></div><div =
style=3D"background-color: rgb(255, 255, 255);"><font face=3D"Arial, sans-s=
erif">Obviously I'm not a security researcher but I do have a good grasp of=
 C++, so just doing my due diligence&nbsp;to check what kind of attack vect=
ors exist in my program's dependencies.</font></div><div style=3D"backgroun=
d-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"Ari=
al, sans-serif">---</font></div><div style=3D"background-color: rgb(255, 25=
5, 255);"><font face=3D"Arial, sans-serif">Ali</font></div><div style=3D"fo=
nt-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); backgro=
und-color: rgb(255, 255, 255);"><br></div><div class=3D"protonmail_quote">
        On Sunday, April 7th, 2024 at 6:33 AM, hashnoncemessage &lt;hashnon=
cemessage@proton.me&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" 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.&nbsp;</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.&nbsp;</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.&nbsp;</div><div dir=3D"auto"><br>=
</div>On Sun, Apr 7, 2024 at 07:57, Ali Sherief &lt;<a href=3D"mailto:On Su=
n, Apr 7, 2024 at 07:57, Ali Sherief <<a href=3D" class=3D"" rel=3D"norefer=
rer nofollow noopener" target=3D"_blank">ali@notatether.com</a>&gt; wrote:<=
blockquote class=3D"protonmail_quote" type=3D"cite">  I am trying to figure=
 out how the Bitcoin Core RPC server stores the UniValue JSON-RPC requests.=
<div><br></div><div>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 t=
hat Core isn't going to send me someone else's JSON-RPC response if somebod=
y else happens to be making a request with that ID at the same instant, whi=
ch could be a potential security issue.</div><div><br></div><div>So far I d=
on't have any leads on the Github codebase yet, but I'm still looking.</div=
><div><br></div><div>Anyway I would appreciate if someone would clarify thi=
s topic for me.</div><div><br></div><div>---</div><div>Ali</div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
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" rel=3D"n=
oreferrer nofollow noopener" target=3D"_blank">bitcoindev+unsubscribe@googl=
egroups.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">https://groups.=
google.com/d/msgid/bitcoindev/a358aaac-62d5-4d30-a599-40c94da66c4fn%40googl=
egroups.com</a>.<br>
</blockquote>
        </blockquote><br>
    </div>
        </blockquote><br>
    </div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; 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/5U7FixH_a7lxjcGGxLi5i-XRPXSVQfMyFHyEfwI532OTI1NoGUkD1=
s8Is3lEj07bL_1znuiEUwRfd7RNTdsA0kRLcRP1BNBZznHDD3YY0Sw%3D%40notatether.com?=
utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/b=
itcoindev/5U7FixH_a7lxjcGGxLi5i-XRPXSVQfMyFHyEfwI532OTI1NoGUkD1s8Is3lEj07bL=
_1znuiEUwRfd7RNTdsA0kRLcRP1BNBZznHDD3YY0Sw%3D%40notatether.com</a>.<br />

--b1_dz10CEF07ZpdMXeDwRZ6FMRamKxfAOMlSbx367YKGE--