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 <user-71895fb2e44c@xymon.invalid>
wrote:
On 17 July 2014 19:57, Ing. Mario De Chenno <user-63e1a68eb0be@xymon.invalid>
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