[Xymon] xymonnet crashes adding a https test

[J.C. 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.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