xymonnet crashes adding a https test
list ING. Mario de Chenno
Hi all, I'm facing a strange crash in xymonnet. I alrady have some https tests configured in hosts.cfg, but when I add the test for a Red Hat Enterprise Virtualization manager web server xymonnet crashes. Here's the affected line: ~/server/etc$ diff hosts.cfg /home/xymon/server/bck/hosts.cfg.OK 70c70 < 10.224.4.120 rhev-mgmt.ceda.unina2.it #ssh https://rhev-mgmt.ceda.unina2.it ---
10.224.4.120 rhev-mgmt.ceda.unina2.it #ssh
If I just remove the 's' to disable ssl testing and leaving http-only the test works: 10.224.4.120 rhev-mgmt.ceda.unina2.it #ssh http://rhev-mgmt.ceda.unina2.it Backtrace follows. Can I further throubleshoot this issue? ~/server$ gdb bin/xymonnet tmp/core GNU gdb (GDB) 7.6.1 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-slackware-linux". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/xymon/server/bin/xymonnet...done. [New LWP 18925] warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? Core was generated by `xymonnet --report --ping --checkresponse --timeout=15'. Program terminated with signal 6, Aborted. #0 0x00007fec5a503dd9 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007fec5a503dd9 in raise () from /lib64/libc.so.6 #1 0x00007fec5a5054e8 in abort () from /lib64/libc.so.6 #2 0x0000000000425693 in sigsegv_handler (signum=<optimized out>) at sig.c:57 #3 <signal handler called> #4 0x00007fec5a556341 in __strlen_sse2 () from /lib64/libc.so.6 #5 0x00007fec5a55604e in strdup () from /lib64/libc.so.6 #6 0x000000000040bd49 in setup_ssl (item=item at entry=0x8074b0) at contest.c:653 #7 0x000000000040d957 in do_tcp_tests (timeout=15, concurrency=256, concurrency at entry=0) at contest.c:1150 #8 0x000000000040532d in main (argc=5, argv=0x7ffffdfd0748) at xymonnet.c:2340
list Thomas Leavitt
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
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.17OK, 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
list Japheth Cleaver
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.htmlThis 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.17OK, 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