Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

(3.8.1) tls cert check segfault (no ca in ca-dir) #1310

Closed
grinapo opened this issue Jan 6, 2017 · 5 comments
Closed

(3.8.1) tls cert check segfault (no ca in ca-dir) #1310

grinapo opened this issue Jan 6, 2017 · 5 comments

Comments

@grinapo
Copy link

grinapo commented Jan 6, 2017 •
edited

Version of syslog-ng

syslog-ng 3.8.1
Installer-Version: 3.8.1
Revision: 3.8.1-9
Module-Directory: /usr/lib/syslog-ng/3.8
Module-Path: /usr/lib/syslog-ng/3.8
Available-Modules: afprog,sdjournal,linux-kmsg-format,json-plugin,basicfuncs,dbparser,syslogformat,add-contextual-data,affile,csvparser,kvformat,date,pseudofile,disk-buffer,afsql,confgen,cryptofuncs,afuser,cef,system-source,afmongodb,afsocket
Enable-Debug: off
Enable-GProf: off
Enable-Memtrace: off
Enable-IPv6: on
Enable-Spoof-Source: on
Enable-TCP-Wrapper: on
Enable-Linux-Caps: off

Platform

Debian/testing

Issue

Test machine uses self-signed cert, and it's not installed in /etc/ssl/certs/. syslog-ng segfaults on the first occasion to send over something through the tls network channel:

[pid 143944] 17:05:45.069870 stat("/etc/ssl/certs//f4ea497f.0", 0x7f1ef7ffc430) = -1 ENOENT (No such file or directory)
[pid 143944] 17:05:45.069936 stat("/etc/ssl/certs//f4ea497f.0", 0x7f1ef7ffc430) = -1 ENOENT (No such file or directory)
[pid 143944] 17:05:45.069960 stat("/etc/ssl/certs//f4ea497f.0", 0x7f1ef7ffc430) = -1 ENOENT (No such file or directory)
[pid 143944] 17:05:45.069989 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x1d0} ---

config

While peer-verify(optional-untrusted) there is a ca-dir in the config, which may confuse the logic. It should not die on it, but definitely not with a SIGSEGV.

gdb

#0  CRYPTO_get_ex_data (ad=0x1d0, idx=idx@entry=0) at crypto/ex_data.c:377
#1  0x00007ffff5b4ef2c in SSL_get_ex_data (s=<optimized out>, idx=idx@entry=0) at ssl/ssl_lib.c:3527
#2  0x00007ffff7b7cb54 in tls_session_verify_callback (ok=0, ctx=0x7fffec00aba0) at ../../lib/tlscontext.c:182
#3  0x00007ffff585d874 in verify_cb_cert (err=<optimized out>, depth=<optimized out>, x=<optimized out>, ctx=<optimized out>) at crypto/x509/x509_vfy.c:162
#4  build_chain (ctx=<optimized out>) at crypto/x509/x509_vfy.c:3209
#5  verify_chain (ctx=0x7fffec00aba0) at crypto/x509/x509_vfy.c:219
#6  0x00007ffff585dc10 in X509_verify_cert (ctx=ctx@entry=0x7fffec00aba0) at crypto/x509/x509_vfy.c:293
#7  0x00007ffff5b460c8 in ssl_verify_cert_chain (s=s@entry=0x555555792240, sk=sk@entry=0x7fffec005170) at ssl/ssl_cert.c:439
#8  0x00007ffff5b586bb in tls_process_server_certificate (s=0x555555792240, pkt=0x7ffff2ea58a0) at ssl/statem/statem_clnt.c:1226
#9  0x00007ffff5b55f1f in read_state_machine (s=0x555555792240) at ssl/statem/statem.c:589
#10 state_machine (s=0x555555792240, server=0) at ssl/statem/statem.c:385
#11 0x00007ffff5b3c2fa in ssl3_write_bytes (s=0x555555792240, type=23, buf_=0x5555557bdf00, len=50) at ssl/record/rec_layer_s3.c:374
#12 0x00007ffff5b4c889 in SSL_write (s=<optimized out>, buf=<optimized out>, num=<optimized out>) at ssl/ssl_lib.c:1605
#13 0x00007ffff7b7d6ea in log_transport_tls_write_method (s=0x555555790070, buf=<optimized out>, buflen=<optimized out>) at ../../lib/transport/transport-tls.c:102
#14 0x00007ffff7b88def in log_transport_write (count=50, buf=<optimized out>, self=<optimized out>) at ../../lib/transport/logtransport.h:45
#15 log_proto_text_client_flush (s=0x55555578f780) at ../../lib/logproto/logproto-text-client.c:54
#16 0x00007ffff7b716a7 in log_proto_client_flush (s=<optimized out>) at ../../lib/logproto/logproto-client.h:110
#17 log_writer_flush_finalize (self=0x5555557bdaa0) at ../../lib/logwriter.c:1083
#18 log_writer_flush (self=0x5555557bdaa0, flush_mode=LW_FLUSH_NORMAL) at ../../lib/logwriter.c:1212
#19 0x00007ffff7b716fa in log_writer_work_perform (s=0x5555557bdaa0) at ../../lib/logwriter.c:185
#20 0x00007ffff7b732dd in _work (self=<optimized out>) at ../../lib/mainloop-io-worker.c:52
#21 0x00007ffff6579ea7 in ?? () from /usr/lib/x86_64-linux-gnu/libivykis.so.0
#22 0x00007ffff65791a3 in ?? () from /usr/lib/x86_64-linux-gnu/libivykis.so.0
#23 0x00007ffff657bb54 in iv_main () from /usr/lib/x86_64-linux-gnu/libivykis.so.0
#24 0x00007ffff6579cd3 in ?? () from /usr/lib/x86_64-linux-gnu/libivykis.so.0
#25 0x00007ffff657c687 in ?? () from /usr/lib/x86_64-linux-gnu/libivykis.so.0
#26 0x00007ffff63600a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#27 0x00007ffff609562d in clone () from /lib/x86_64-linux-gnu/libc.so.6
@grinapo
Copy link
Author

grinapo commented Jan 6, 2017

It works in

syslog-ng 3.7.3
Installer-Version: 3.7.3
Revision: 3.7.3-1
Compile-Date: Jul 16 2016 07:55:58
Available-Modules: afprog,sdjournal,linux-kmsg-format,json-plugin,basicfuncs,dbparser,syslogformat,affile,csvparser,kvformat,pseudofile,afsql,confgen,cryptofuncs,afuser,system-source,afmongodb,afsocket
Enable-Debug: off
Enable-GProf: off
Enable-Memtrace: off
Enable-IPv6: on
Enable-Spoof-Source: on
Enable-TCP-Wrapper: on
Enable-Linux-Caps: off

@grinapo grinapo mentioned this issue Jan 9, 2017
Closed
@ckujau ckujau mentioned this issue Jan 31, 2017
Closed
@bazsi
Copy link
Collaborator

bazsi commented Feb 4, 2017

Please supply a "signed-off-by" line so that I can merge the fix.

Thanks.

@bazsi
Copy link
Collaborator

bazsi commented Feb 4, 2017

I mean to the PR #1316

@grinapo
Copy link
Author

grinapo commented Feb 5, 2017

Oh I sign off everything, including death certificates and world peace™. You name it, I sign it off. If you're lucky even with my own name. ;)

bazsi added a commit that referenced this issue Feb 6, 2017
@bazsi
tlscontext: fix segfault in X509_STORE_CTX_get_app_data(ctx)
2251fa7 
This patch fixes a potential segfault during X.509 certificate validation.
What happens is that X509_STORE_CTX contains "application data", e.g.
the application is able to associate a series of pointers with the validation.

This uses an "id" to identify the user of the specific pointer.

This mechanism is used by the SSL library (still in openssl) to store the
pointer to the SSL session. The ID for this data is normally 0, however
if libssl.so is unloaded while libcrypto.so is not, it might happen
that this ID gets remapped to a non-zero value.

Then what leads to the crash is that libssl starts to use ID 1
to manage its SSL* pointer, while we in the validation code still
use ID 0, causing a NULL deref.

The exact reasons why this ID change happens is unclear, some apache
related information can be found here:

https://bz.apache.org/bugzilla/show_bug.cgi?id=32529

You can also find more information in github issue #1310.

Signed-off-by: Peter Gervai <grin@grin.hu>
Signed-off-by: Balazs Scheidler <balazs.scheidler@balabit.com>
@bazsi
Copy link
Collaborator

bazsi commented Feb 6, 2017

Closing with the fix in #1316

@bazsi bazsi closed this as completed Feb 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@bazsi @grinapo