Hi Thomas,
I actually just replied back, but I think the address was incorrect.
On Tue, December 29, 2015 9:54 am, Thomas Leavitt wrote:
I think I've just run into this same https / RHEV SSL certificate crashing Xymonnet issue. I've emailed everyone offline, but I thought I'd also drop a message here, in case anyone else has run into it, or I missed something about a resolution. I've confirmed that this problem is not triggered on non-RHEV sites.
I'm using the terabithia RPMs on Scientific Linux.
Regards, Thomas Leavitt
file core.4818 core.4818: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'xymonnet --report --ping --checkresponse'
gdb /usr/libexec/xymon/xymonnet core.4818 GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-64.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/libexec/xymon/xymonnet...Reading symbols from /usr/libexec/xymon/xymonnet...(no debugging symbols found)...done. (no debugging symbols found)...done. [New LWP 4818] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `xymonnet --report --ping --checkresponse'. Program terminated with signal 6, Aborted. #0 0x00007f9942cf65f7 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install xymon-4.3.24-3.el7.x86_64
Can you install the xymon-debuginfo-4.3.24-3.el7.x86_64 RPM, followed by the "debuginfo-install" command listed here? That will install the symbol needed, and the symbols for any shared libraries referenced, to get a stack trace.
On Thu, Jul 17, 2014 at 9:57 PM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:
On 17 July 2014 19:57, Ing. Mario De Chenno <mario.dechenno at unina2.it> wrote:
4.3.17
OK, I think it's a bug caused by a malformed certificate. In this line:
certstart = strdup(xymon_ASN1_UTCTIME(X509_get_notBefore(peercert)));
strdup() will segfault if it gets a null parameter. xymon_ASN1_UTCTIME() returns a null parameter if X509_get_notBefore() returns a value that's too small in size, and perhaps if it returns null.
I think something like this would be better:
certstart_p = xymon_ASN1_UTCTIME(X509_get_notBefore(peercert)); if (certstart_p == NULL){ errprintf("Invalid certificate\n"); return NULL; } certstart = strdup(certstart_p);
In fact probably better to use strndup() to reduce the risk of buffer overflows.
Please note: I'm not a programmer, and the above code is untested, probably contains bugs, and may cause your house to burn down and other nasty things.
Cheers Jeremy
If you could send a current stack trace that would definitely be very helpful.
The source from 07/2014 has line-shifted since then, but the only strdup()'s we have now in setup_ssl are still centered around certificate parsing, so a problematic certificate could still cause a problem there. I think I missed this discussion last year, but I'll put in some safer parsing now.
If it's crashing in the same place, is there any chance there's something unusual about those fields for the certificates responding back on your site? Any chance you could do an openssl s_connect on it, or provide a link if it's publically accessible?
Regards, -jc