View Issue Details

IDProjectCategoryView StatusLast Update
0004878GNUnetcadet servicepublic2018-06-07 00:24
Reporteramatus Assigned ToChristian Grothoff  
PrioritynormalSeveritymajorReproducibilityhave not tried
Status closedResolutionfixed 
Product VersionGit master 
Target Version0.11.0pre66Fixed in Version0.11.0pre66 
Summary0004878: heap-use-after-free in send_kx_auth
DescriptionMy 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
TagsNo tags attached.

Activities

amatus

2017-02-11 16:37

developer   ~0011712

Hit this again at a03d291e3253572b19712918759011198118b3b2

Christian Grothoff

2017-02-15 15:57

manager   ~0011762

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.

amatus

2017-02-15 16:07

developer   ~0011763

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;

Christian Grothoff

2017-02-15 16:41

manager   ~0011764

Ah, good point, will fix.

Christian Grothoff

2017-02-15 16:55

manager   ~0011765

Fixed in e6fbcee2510d7263b53d7a5c7cf1fc1d4a7bbdd6

Issue History

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