SIGSEGV simple gloox client

Question

I've been trying to use gloox 1.0.14 for the first time and I think I'm using the most minimal example there is but poorly I get a SIGSEGV. Can anyone reproduce this problem or tell me why this happens and what I'm doing wrong? It's seems to be that the JID has an impact on this but I'd expect it to throw an error instead of segv crashing and the JID seems valid to me and even if the certificate is incorrect or whatever I'd still expect it to throw instead.

#include <cstdlib>

#include "gloox/client.h"

int main() {
  gloox::JID jid("segv@jabber.de");
  gloox::Client client(jid, "password");
  client.connect();
  return EXIT_SUCCESS;
}

Sanitizer told me:

ASAN:SIGSEGV
=================================================================
==27028==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f6357f79acd bp 0x7ffcca7c1a50 sp 0x7ffcca7c17d0 T0)
    #0 0x7f6357f79acc  (/lib64/libgnutls.so.30+0x99acc)
    #1 0x7f6357f7b49a  (/lib64/libgnutls.so.30+0x9b49a)
    #2 0x7f6357f7bb18 in gnutls_x509_crt_verify (/lib64/libgnutls.so.30+0x9bb18)
    #3 0x7f635a4ad54b in gloox::GnuTLSClient::verifyAgainstCAs(gnutls_x509_crt_int*, gnutls_x509_crt_int**, int) (/lib64/libgloox.so.13+0xbd54b)
    #4 0x7f635a4ad6bf in gloox::GnuTLSClient::getCertInfo() (/lib64/libgloox.so.13+0xbd6bf)
    #5 0x7f635a4afd6c in gloox::GnuTLSBase::handshake() (/lib64/libgloox.so.13+0xbfd6c)
    #6 0x7f635a4afbc0 in gloox::GnuTLSBase::decrypt(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (/lib64/libgloox.so.13+0xbfbc0)
    #7 0x7f635a4490bb in gloox::ConnectionTCPClient::recv(int) (/lib64/libgloox.so.13+0x590bb)
    #8 0x7f635a4c297d in gloox::ConnectionTCPBase::receive() (/lib64/libgloox.so.13+0xd297d)
    #9 0x7f635a4541d7 in gloox::ClientBase::connect(bool) (/lib64/libgloox.so.13+0x641d7)
    #10 0x4014d7 in main test.cc:8
    #11 0x7f6358aa357f in __libc_start_main (/lib64/libc.so.6+0x2057f)
    #12 0x401198 in _start (test+0x401198)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 ??
==27028==ABORTING

I compiled via:

c++ -fsanitize=address -fsanitize=undefined -ggdb -std=c++14 -Wall -Wextra -Wpedantic -Wconversion -Wsign-conversion -lgloox main.cc

Answer 1

This looks like a bug in recent version of gloox . Running the code under gdb or valgrind (without sanitizer) shows nice backtrace.

Full backtrace from valgrind points to the place of problem:

==29533==    at 0x62B558D: verify_crt (verify.c:602)
==29533==    by 0x62B6F57: _gnutls_verify_crt_status (verify.c:936)
==29533==    by 0x62B75CC: gnutls_x509_crt_verify (verify.c:1329)
==29533==    by 0x4EF254B: gloox::GnuTLSClient::verifyAgainstCAs(gnutls_x509_crt_int*, gnutls_x509_crt_int**, int) (tlsgnutlsclient.cpp:227)
==29533==    by 0x4EF26BF: gloox::GnuTLSClient::getCertInfo() (tlsgnutlsclient.cpp:157)
==29533==    by 0x4EF4D6C: gloox::GnuTLSBase::handshake() (tlsgnutlsbase.cpp:138)
==29533==    by 0x4EF4BC0: gloox::GnuTLSBase::decrypt(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (tlsgnutlsbase.cpp:70)
==29533==    by 0x4E8E0BB: gloox::ConnectionTCPClient::recv(int) (connectiontcpclient.cpp:169)
==29533==    by 0x4F0797D: gloox::ConnectionTCPBase::receive() (connectiontcpbase.cpp:115)
==29533==    by 0x4E991D7: gloox::ClientBase::connect(bool) (clientbase.cpp:212)
==29533==    by 0x400DAC: main (main.cc:9)

Backtrace from gdb shows:

#0  verify_crt (cert=0xbebebebebebebebe, trusted_cas=trusted_cas@entry=0x0, tcas_size=tcas_size@entry=0, flags=flags@entry=0, output=output@entry=0x7fffffffce90, _issuer=_issuer@entry=0x7fffffffce98, 
    now=1455405710, max_path=0x7fffffffce94, end_cert=true, nc=0x602000007a50, func=0x0) at verify.c:602
#1  0x00007ffff46bcf58 in _gnutls_verify_crt_status (certificate_list=certificate_list@entry=0x7fffffffcf08, clist_size=clist_size@entry=1, trusted_cas=trusted_cas@entry=0x0, tcas_size=tcas_size@entry=0, 
    flags=flags@entry=0, purpose=purpose@entry=0x0, func=0x0) at verify.c:936
#2  0x00007ffff46bd5cd in gnutls_x509_crt_verify (cert=cert@entry=0xbebebebebebebebe, CA_list=CA_list@entry=0x0, CA_list_length=CA_list_length@entry=0, flags=flags@entry=0, verify=verify@entry=0x7fffffffcf24)
    at verify.c:1329
#3  0x00007ffff6bee54c in gloox::GnuTLSClient::verifyAgainstCAs (this=this@entry=0x61400000fc40, cert=0xbebebebebebebebe, CAList=CAList@entry=0x0, CAListSize=CAListSize@entry=0) at tlsgnutlsclient.cpp:227
#4  0x00007ffff6bee6c0 in gloox::GnuTLSClient::getCertInfo (this=0x61400000fc40) at tlsgnutlsclient.cpp:157
#5  0x00007ffff6bf0d6d in gloox::GnuTLSBase::handshake (this=0x61400000fc40) at tlsgnutlsbase.cpp:138
#6  0x00007ffff6bf0bc1 in gloox::GnuTLSBase::decrypt (this=0x61400000fc40, 
    data="\024\003\003\000\001\001\026\003\003\000(\373\336\267\221q\256\266\344\363\022\367 C\022\233\351\251\065\036\355\070\362\217\264\370\003\206+\"\201r^\355\067I\203Y\213\350\301")
    at tlsgnutlsbase.cpp:70
#7  0x00007ffff6b8a0bc in gloox::ConnectionTCPClient::recv (this=<optimized out>, timeout=<optimized out>) at connectiontcpclient.cpp:169
#8  0x00007ffff6c0397e in gloox::ConnectionTCPBase::receive (this=0x60c00000bec0) at connectiontcpbase.cpp:115
#9  0x00007ffff6b951d8 in gloox::ClientBase::connect (this=0x7fffffffd410, block=<optimized out>) at clientbase.cpp:212
#10 0x00000000004013a8 in main () at main.cc:9

cert=0xbebebebebebebebe pointer is the point of failure. It is brought to that place from frame 4 in tlsgnutlsclient.cpp:157 , where is such fanny construct:

157     m_certInfo.chain = verifyAgainstCAs( cert[certListSize], 0 /*CAList*/, 0 /*CAListSize*/ );

cert[certListSize] is clearly pointing away from the existing array. I tried to trace the bug in sources, but I am not so skilled with the svn commandline tools so I am leaving this on the reported to fill upstream bug (ok, I can do that, but let me know if there is anything I can do for you).