Xymon Mailing List Archive search

xymonnet crashes adding a https test

3 messages in this thread

list ING. Mario de Chenno · Wed, 02 Jul 2014 09:50:21 +0200 ·
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 · Tue, 29 Dec 2015 09:54:23 -0800 ·
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
quoted from ING. Mario de Chenno
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".
quoted from ING. Mario de Chenno
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.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

list Japheth Cleaver · Tue, 29 Dec 2015 10:03:16 -0800 ·
Hi Thomas,

I actually just replied back, but I think the address was incorrect.
quoted from Thomas Leavitt


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.
quoted from Thomas Leavitt

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