View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004878 | GNUnet | cadet service | public | 2017-02-02 03:33 | 2018-06-07 00:24 |
Reporter | amatus | Assigned To | Christian Grothoff | ||
Priority | normal | Severity | major | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | Git master | ||||
Target Version | 0.11.0pre66 | Fixed in Version | 0.11.0pre66 | ||
Summary | 0004878: heap-use-after-free in send_kx_auth | ||||
Description | My peer running 68ab49e28a51b4d877cbd37ad10868a482133c52 hit this. | ||||
Additional Information | ================================================================= ==31274==ERROR: AddressSanitizer: heap-use-after-free on address 0x603000169060 at pc 0x7f8a05190792 bp 0x7ffef04d5f10 sp 0x7ffef04d56d0 READ of size 32 at 0x603000169060 thread T0 #0 0x7f8a05190791 (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x2e791) #1 0x7f8a02ad49a3 (/lib/x86_64-linux-gnu/libgcrypt.so.20+0xe9a3) #2 0x7f8a02ad5c1e (/lib/x86_64-linux-gnu/libgcrypt.so.20+0xfc1e) #3 0x7f8a02acf1ae in gcry_sexp_build (/lib/x86_64-linux-gnu/libgcrypt.so.20+0x91ae) #4 0x7f8a04e7f858 in decode_private_ecdhe_key /root/gnunet/src/util/crypto_ecc.c:196 #5 0x7f8a04e801bf in GNUNET_CRYPTO_ecdhe_key_get_public /root/gnunet/src/util/crypto_ecc.c:282 #6 0x42624c in send_kx_auth /root/gnunet/src/cadet/gnunet-service-cadet-new_tunnels.c:1411 #7 0x427ca4 in GCT_handle_kx /root/gnunet/src/cadet/gnunet-service-cadet-new_tunnels.c:1709 #8 0x417c52 in GCC_handle_kx /root/gnunet/src/cadet/gnunet-service-cadet-new_connection.c:539 #9 0x41f4c1 in handle_tunnel_kx /root/gnunet/src/cadet/gnunet-service-cadet-new_core.c:1083 #10 0x7f8a04eaa00e in GNUNET_MQ_inject_message /root/gnunet/src/util/mq.c:265 #11 0x7f8a049e2c76 in handle_notify_inbound /root/gnunet/src/core/core_api.c:651 #12 0x7f8a04eaa00e in GNUNET_MQ_inject_message /root/gnunet/src/util/mq.c:265 #13 0x7f8a04e44eba in recv_message /root/gnunet/src/util/client.c:301 #14 0x7f8a04ea9047 in GNUNET_MST_from_buffer /root/gnunet/src/util/mst.c:232 #15 0x7f8a04ea9b35 in GNUNET_MST_read /root/gnunet/src/util/mst.c:359 #16 0x7f8a04e458ba in receive_ready /root/gnunet/src/util/client.c:383 #17 0x7f8a04ecc545 in run_ready /root/gnunet/src/util/scheduler.c:620 #18 0x7f8a04ecd204 in GNUNET_SCHEDULER_run /root/gnunet/src/util/scheduler.c:887 #19 0x7f8a04ef1c2c in GNUNET_SERVICE_ruN_ /root/gnunet/src/util/service_new.c:1864 #20 0x409c89 in main /root/gnunet/src/cadet/gnunet-service-cadet-new.c:1413 #21 0x7f8a0370bb44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44) #22 0x403f58 (/opt/gnunet/lib/gnunet/libexec/gnunet-service-cadet-new+0x403f58) 0x603000169060 is located 0 bytes inside of 32-byte region [0x603000169060,0x603000169080) freed by thread T0 here: #0 0x7f8a051b6527 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x54527) #1 0x7f8a04e496c3 in GNUNET_xfree_ /root/gnunet/src/util/common_allocation.c:330 #2 0x421cef in new_ephemeral /root/gnunet/src/cadet/gnunet-service-cadet-new_tunnels.c:651 #3 0x422495 in t_ax_encrypt /root/gnunet/src/cadet/gnunet-service-cadet-new_tunnels.c:785 #4 0x42f886 in GCT_send /root/gnunet/src/cadet/gnunet-service-cadet-new_tunnels.c:3189 #5 0x40b3da in send_channel_open /root/gnunet/src/cadet/gnunet-service-cadet-new_channel.c:569 #6 0x7f8a04ecc545 in run_ready /root/gnunet/src/util/scheduler.c:620 #7 0x7f8a04ecd204 in GNUNET_SCHEDULER_run /root/gnunet/src/util/scheduler.c:887 #8 0x7f8a04ef1c2c in GNUNET_SERVICE_ruN_ /root/gnunet/src/util/service_new.c:1864 #9 0x409c89 in main /root/gnunet/src/cadet/gnunet-service-cadet-new.c:1413 #10 0x7f8a0370bb44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44) previously allocated by thread T0 here: #0 0x7f8a051b673f in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x5473f) #1 0x7f8a04e4937a in GNUNET_xmalloc_unchecked_ /root/gnunet/src/util/common_allocation.c:227 #2 0x7f8a04e48b14 in GNUNET_xmalloc_ /root/gnunet/src/util/common_allocation.c:75 #3 0x7f8a04e80f46 in GNUNET_CRYPTO_ecdhe_key_create /root/gnunet/src/util/crypto_ecc.c:530 #4 0x421cfb in new_ephemeral /root/gnunet/src/cadet/gnunet-service-cadet-new_tunnels.c:654 #5 0x42e28d in GCT_create_tunnel /root/gnunet/src/cadet/gnunet-service-cadet-new_tunnels.c:2919 #6 0x439398 in GCP_get_tunnel /root/gnunet/src/cadet/gnunet-service-cadet-new_peer.c:1247 #7 0x40bd59 in GCCH_channel_local_new /root/gnunet/src/cadet/gnunet-service-cadet-new_channel.c:664 #8 0x405270 in handle_channel_create /root/gnunet/src/cadet/gnunet-service-cadet-new.c:581 #9 0x7f8a04eaa00e in GNUNET_MQ_inject_message /root/gnunet/src/util/mq.c:265 #10 0x7f8a04ef3263 in service_client_mst_cb /root/gnunet/src/util/service_new.c:2126 #11 0x7f8a04ea9047 in GNUNET_MST_from_buffer /root/gnunet/src/util/mst.c:232 #12 0x7f8a04ea9b35 in GNUNET_MST_read /root/gnunet/src/util/mst.c:359 #13 0x7f8a04ef335a in service_client_recv /root/gnunet/src/util/service_new.c:2147 #14 0x7f8a04ecc545 in run_ready /root/gnunet/src/util/scheduler.c:620 #15 0x7f8a04ecd204 in GNUNET_SCHEDULER_run /root/gnunet/src/util/scheduler.c:887 #16 0x7f8a04ef1c2c in GNUNET_SERVICE_ruN_ /root/gnunet/src/util/service_new.c:1864 #17 0x409c89 in main /root/gnunet/src/cadet/gnunet-service-cadet-new.c:1413 #18 0x7f8a0370bb44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44) SUMMARY: AddressSanitizer: heap-use-after-free ??:0 ?? Shadow bytes around the buggy address: 0x0c06800251b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c06800251c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c06800251d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c06800251e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c06800251f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c0680025200: fa fa fa fa fa fa fa fa fa fa fa fa[fd]fd fd fd 0x0c0680025210: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0680025220: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0680025230: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0680025240: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0680025250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Contiguous container OOB:fc ASan internal: fe ==31274==ABORTING | ||||
Tags | No tags attached. | ||||
|
Hit this again at a03d291e3253572b19712918759011198118b3b2 |
|
This is VERY strange. The line in 'new_ephemeral()' where the (key's) memory is freed is immediately followed by an allocation of a fresh key object. The logic is pretty simple here, just look at 'new_ephemeral()' and tell me how this could cause such a bug in send_kx_auth(). So as far as I see it, something about the report must be wrong. |
|
I think the problem is we're freeing t->ax->DHRs which turns t->unverified_ax->DHRs into a dangling pointer. There's even a comment telling us that copying this pointer was dangerous: /** * ECDH Ratchet key (our private key in the current DH). Note that * for the 'unverified_ax', this member is an alias with the main * 't->ax.kx_0' value, so do not free it! */ struct GNUNET_CRYPTO_EcdhePrivateKey *DHRs; |
|
Ah, good point, will fix. |
|
Fixed in e6fbcee2510d7263b53d7a5c7cf1fc1d4a7bbdd6 |
Date Modified | Username | Field | Change |
---|---|---|---|
2017-02-02 03:33 | amatus | New Issue | |
2017-02-02 03:33 | amatus | Status | new => assigned |
2017-02-02 03:33 | amatus | Assigned To | => Bart Polot |
2017-02-11 16:37 | amatus | Note Added: 0011712 | |
2017-02-15 15:57 | Christian Grothoff | Note Added: 0011762 | |
2017-02-15 16:07 | amatus | Note Added: 0011763 | |
2017-02-15 16:41 | Christian Grothoff | Note Added: 0011764 | |
2017-02-15 16:42 | Christian Grothoff | Assigned To | Bart Polot => Christian Grothoff |
2017-02-15 16:55 | Christian Grothoff | Note Added: 0011765 | |
2017-02-15 16:55 | Christian Grothoff | Status | assigned => resolved |
2017-02-15 16:55 | Christian Grothoff | Resolution | open => fixed |
2017-02-15 16:55 | Christian Grothoff | Fixed in Version | => 0.11.0pre66 |
2017-02-15 16:55 | Christian Grothoff | Target Version | => 0.11.0pre66 |
2018-06-07 00:24 | Christian Grothoff | Status | resolved => closed |