[Pkg-openssl-devel] Bug#642524: libssl1.0.0: crash when using DTLS1

[Nikos Mavrogiannopoulos]

Package: libssl1.0.0
Version: 1.0.0e-2
Severity: important
Tags: upstream

Dear Maintainer,

   * What led up to the situation?
Trying to establish a DTLS server and connecting with a client makes the server
crash. I used the openssl utility for that.

$ openssl s_server -accept 5555 -keyform pem -certform pem -dtls1 -mtu 1000
-timeout -key certs/rsa-2432.pem -cert certs/cert-rsa-2432.pem
$ openssl s_client -port 5555 -dtls1 -host localhost

The commands above make the  server crash. I attach the valgrind output.





-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libssl1.0.0 depends on:
ii  debconf [debconf-2.0]  1.5.41          
ii  libc6                  2.13-20         
ii  multiarch-support      2.13-20         
ii  zlib1g                 1:1.2.3.4.dfsg-3

libssl1.0.0 recommends no packages.

libssl1.0.0 suggests no packages.

-- debconf information:
  libssl1.0.0/restart-failed:
  libssl1.0.0/restart-services:
-------------- next part --------------
==24804== Memcheck, a memory error detector
==24804== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==24804== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==24804== Command: openssl s_server -accept 5555 -keyform pem -certform pem -dtls1 -mtu 1000 -timeout -key ../certs/rsa-2432.pem -cert ../certs/cert-rsa-2432.pem
==24804== 
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
==24804== Source and destination overlap in memcpy(0x5c6c29d, 0x5c62760, -13)
==24804==    at 0x4C28DF6: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24804==    by 0x4E59D3A: do_dtls1_write (d1_pkt.c:1456)
==24804==    by 0x4E5B481: dtls1_do_write (d1_both.c:331)
==24804==    by 0x4E562F5: dtls1_accept (d1_srvr.c:758)
==24804==    by 0x436280: ??? (in /usr/bin/openssl)
==24804==    by 0x436676: ??? (in /usr/bin/openssl)
==24804==    by 0x44C0AB: ??? (in /usr/bin/openssl)
==24804==    by 0x43A1BD: ??? (in /usr/bin/openssl)
==24804==    by 0x41A73E: ??? (in /usr/bin/openssl)
==24804==    by 0x41A26D: ??? (in /usr/bin/openssl)
==24804==    by 0x587EEAC: (below main) (libc-start.c:228)
==24804== 
==24804== Invalid read of size 1
==24804==    at 0x4C28FF0: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24804==    by 0x4E59D3A: do_dtls1_write (d1_pkt.c:1456)
==24804==    by 0x4E5B481: dtls1_do_write (d1_both.c:331)
==24804==    by 0x4E562F5: dtls1_accept (d1_srvr.c:758)
==24804==    by 0x436280: ??? (in /usr/bin/openssl)
==24804==    by 0x436676: ??? (in /usr/bin/openssl)
==24804==    by 0x44C0AB: ??? (in /usr/bin/openssl)
==24804==    by 0x43A1BD: ??? (in /usr/bin/openssl)
==24804==    by 0x41A73E: ??? (in /usr/bin/openssl)
==24804==    by 0x41A26D: ??? (in /usr/bin/openssl)
==24804==    by 0x587EEAC: (below main) (libc-start.c:228)
==24804==  Address 0x105c62752 is not stack'd, malloc'd or (recently) free'd
==24804== 
==24804== 
==24804== Process terminating with default action of signal 11 (SIGSEGV)
==24804==  Access not within mapped region at address 0x105C62752
==24804==    at 0x4C28FF0: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24804==    by 0x4E59D3A: do_dtls1_write (d1_pkt.c:1456)
==24804==    by 0x4E5B481: dtls1_do_write (d1_both.c:331)
==24804==    by 0x4E562F5: dtls1_accept (d1_srvr.c:758)
==24804==    by 0x436280: ??? (in /usr/bin/openssl)
==24804==    by 0x436676: ??? (in /usr/bin/openssl)
==24804==    by 0x44C0AB: ??? (in /usr/bin/openssl)
==24804==    by 0x43A1BD: ??? (in /usr/bin/openssl)
==24804==    by 0x41A73E: ??? (in /usr/bin/openssl)
==24804==    by 0x41A26D: ??? (in /usr/bin/openssl)
==24804==    by 0x587EEAC: (below main) (libc-start.c:228)
==24804==  If you believe this happened as a result of a stack
==24804==  overflow in your program's main thread (unlikely but
==24804==  possible), you can try to increase the size of the
==24804==  main thread stack using the --main-stacksize= flag.
==24804==  The main thread stack size used in this run was 8388608.
==24804== 
==24804== HEAP SUMMARY:
==24804==     in use at exit: 202,145 bytes in 3,732 blocks
==24804==   total heap usage: 4,303 allocs, 571 frees, 277,934 bytes allocated
==24804== 
==24804== LEAK SUMMARY:
==24804==    definitely lost: 0 bytes in 0 blocks
==24804==    indirectly lost: 0 bytes in 0 blocks
==24804==      possibly lost: 0 bytes in 0 blocks
==24804==    still reachable: 202,145 bytes in 3,732 blocks
==24804==         suppressed: 0 bytes in 0 blocks
==24804== Rerun with --leak-check=full to see details of leaked memory
==24804== 
==24804== For counts of detected and suppressed errors, rerun with: -v
==24804== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)