[gnutls-help] Issues with libcurl and GnuTLS 3.2

Apollon Oikonomopoulos apoikos at debian.org
Tue Jun 24 15:20:54 CEST 2014


On 15:13 Mon 23 Jun     , Apollon Oikonomopoulos wrote:
>  - With the same version of libcurl (7.37.0) linked against gnutls 
>    2.12, luxid
>    works reliably. Actually the bug appeared when Debian switched to a gnutls
>    3.2-linked version of libcurl. I tried out different combinations of 
>    libcurl and GnuTLS versions, the only failing combinations were with 
>    GnuTLS 3.2. 

> --- Backtrace
> #0  0x00007fcce89d0002 in __gmpn_powm () from /usr/lib/x86_64-linux-gnu/libgmp.so.10
> No symbol table info available.
> #1  0x00007fcce8997a8d in __gmpz_powm () from /usr/lib/x86_64-linux-gnu/libgmp.so.10
> No symbol table info available.
> #2  0x00007fcce59fdbf2 in _nettle_rsa_blind (pub=pub at entry=0x7fff9b21a230, random_ctx=random_ctx at entry=0x0, random=random at entry=0x7fcce73ec5e0 <rnd_func>, c=c at entry=0x7fff9b21a220, ri=ri at entry=0x7fff9b21a1b0) at rsa-blind.c:56
>         r = {{_mp_alloc = 33, _mp_size = 32, _mp_d = 0x7fcce470f9b8}}

The good news is that this is no GnuTLS bug.

For future reference, the problem seems to be in GMP's memory 
management: GHC by default uses GMP for its Integer and Fractional 
implementation[1]; binaries produced by GHC embed the GHC runtime and 
are linked with libgmp. GMP in turn uses a per-process memory heap, 
which in the GHC RTS case is managed by the Haskell garbage collector 
using mp_set_memory_functions((*alloc)(), (*realloc)(), 
(*dealloc)())[1]. The Garbage Collector in turn probably assumes that 
this heap should contain Haskell objects known to itself exclusively.

Now, gnutls28 pulls in and uses libgmp as well (via nettle), but this 
use is opaque to the Haskell garbage collector, since the gmp function 
calls happen way below the GHC runtime and their results are not bound 
to Haskell objects. Eventually a Haskell GC run will overwrite the data 
used by any FFI calls to libraries using GMP themselves, causing 
extensive memory corruption of the key material as seen in the 
backtrace. This explains both, the segfaults and the "Decrypt errors" 

gnutls26 does not use nettle/GMP and that is why the problem does not 

[1] https://ghc.haskell.org/trac/ghc/wiki/ReplacingGMPNotes


More information about the Gnutls-help mailing list