Xymon 4.3.29 Released - Important Security Update 🔗 link

On 7/23/2019 8:57 AM, Japheth Cleaver wrote:

Hello all,

Xymon 4.3.29 has been released to Sourceforge and should be propagating to mirrors as I write this. Along with an assortment of bug fixes and compilation compatibility fixes for recent glibc systems, this version contains several fixes for security vulnerabilities within some CGI parsing. Although some of these overflows are not exploitable, others, including an XSS vulnerability are. Fixes beyond these CVEs have been made throughout the library, web, and network code to help reduce the likelihood of similar issues in other areas. As a result, all users are encouraged to upgrade.

The specific CVEs in question are:
? CVE-2019-13451, CVE-2019-13452, CVE-2019-13455, CVE-2019-13473,
? CVE-2019-13474, CVE-2019-13484, CVE-2019-13485, CVE-2019-13486

Henrik and I would like to extend our thanks to the University of Cambridge Computer Security
Incident Response Team, which reported the issues and helped validate their resolution.

Full release notes and other changes are available with the released tarball at https://sourceforge.net/projects/xymon/files/Xymon/4.3.29/

As always, thank you to everyone who has contributed patches, ideas, code, and feature requests to the project!


Sincerely,
Japheth "J.C." Cleaver

On 7/23/2019 8:57 AM, Japheth Cleaver wrote:

Hello all,

Xymon 4.3.29 has been released to Sourceforge and should be propagating to mirrors as I write this. Along with an assortment of bug fixes and compilation compatibility fixes for recent glibc systems, this version contains several fixes for security vulnerabilities within some CGI parsing. Although some of these overflows are not exploitable, others, including an XSS vulnerability are. Fixes beyond these CVEs have been made throughout the library, web, and network code to help reduce the likelihood of similar issues in other areas. As a result, all users are encouraged to upgrade.

The specific CVEs in question are:
? CVE-2019-13451, CVE-2019-13452, CVE-2019-13455, CVE-2019-13473,
? CVE-2019-13474, CVE-2019-13484, CVE-2019-13485, CVE-2019-13486

On Jul 23, 2019, at 12:11, Japheth Cleaver <user-87556346d4af@xymon.invalid> wrote:

On 7/23/2019 8:57 AM, Japheth Cleaver wrote:

Hello all,

Xymon 4.3.29 has been released to Sourceforge and should be propagating to mirrors as I write this. Along with an assortment of bug fixes and compilation compatibility fixes for recent glibc systems, this version contains several fixes for security vulnerabilities within some CGI parsing. Although some of these overflows are not exploitable, others, including an XSS vulnerability are. Fixes beyond these CVEs have been made throughout the library, web, and network code to help reduce the likelihood of similar issues in other areas. As a result, all users are encouraged to upgrade.

The specific CVEs in question are:
  CVE-2019-13451, CVE-2019-13452, CVE-2019-13455, CVE-2019-13473,
  CVE-2019-13474, CVE-2019-13484, CVE-2019-13485, CVE-2019-13486

For clarification, the above CVEs only affect the *server* side of the Xymon monitoring system. Xymon clients are not affected.

-jc

On Jul 24, 2019, at 08:46, Richard L. Hamilton <user-af55987f6d56@xymon.invalid> wrote:

gcc prior to 4.6 gives the errors:

acklog.c: In function ?do_acklog?:
acklog.c:129:12: error: #pragma GCC diagnostic not allowed inside functions
acklog.c:130:12: error: #pragma GCC diagnostic not allowed inside functions
acklog.c:132:12: error: #pragma GCC diagnostic not allowed inside functions

Discussion of other software with a similar problem suggests a gcc version test for those.  Or just comment out those lines, for those who don't
want to install a newer gcc and don't want to wait for a version test to be added.

On Jul 23, 2019, at 12:11, Japheth Cleaver <user-87556346d4af@xymon.invalid> wrote:

On 7/23/2019 8:57 AM, Japheth Cleaver wrote:

Hello all,

Xymon 4.3.29 has been released to Sourceforge and should be propagating to mirrors as I write this. Along with an assortment of bug fixes and compilation compatibility fixes for recent glibc systems, this version contains several fixes for security vulnerabilities within some CGI parsing. Although some of these overflows are not exploitable, others, including an XSS vulnerability are. Fixes beyond these CVEs have been made throughout the library, web, and network code to help reduce the likelihood of similar issues in other areas. As a result, all users are encouraged to upgrade.

The specific CVEs in question are:
 CVE-2019-13451, CVE-2019-13452, CVE-2019-13455, CVE-2019-13473,
 CVE-2019-13474, CVE-2019-13484, CVE-2019-13485, CVE-2019-13486

For clarification, the above CVEs only affect the *server* side of the Xymon monitoring system. Xymon clients are not affected.

-jc

On Tue, Jul 23, 2019 at 08:57:49AM -0700, Japheth Cleaver wrote:

Although some of these overflows are not exploitable, others, including an
XSS vulnerability are.

[...

? CVE-2019-13451, CVE-2019-13452, CVE-2019-13455, CVE-2019-13473,
? CVE-2019-13474, CVE-2019-13484, CVE-2019-13485, CVE-2019-13486

On 7/24/2019 7:01 AM, Stephen Carville (xymon list) wrote:

On 7/23/19 9:08 AM, Japheth Cleaver wrote:

Lereta Email Checkpoint: External email. Please make sure you trust this
source before clicking links or opening attachments.

**********************************************************************

Just an FYI.  When I updated my CentOS 7 xymon server by building from
source, it refused to include the openssl libraries until I installed
the libtirpc-devel package.  Not sure why it is necessary.

On 7/24/2019 6:54 AM, Axel Beckert wrote:

Hi,

On Tue, Jul 23, 2019 at 08:57:49AM -0700, Japheth Cleaver wrote:

Although some of these overflows are not exploitable, others, including an
XSS vulnerability are.

[...

 ? CVE-2019-13451, CVE-2019-13452, CVE-2019-13455, CVE-2019-13473,
 ? CVE-2019-13474, CVE-2019-13484, CVE-2019-13485, CVE-2019-13486

Can either you or Graham get a bit more into the details regarding the
impact of any of these vulnerabilities ? or point out a posting where
they are explained in more detail? So far I wasn't able to dig up any
posting or similar, e.g. by the Cambridge CSIRT or Graham.

Currently the severity as well as the actual impact of these issues is
quite unclear ? also because the CVE-IDs all still say "RESERVED".

		Regards, Axel

On 7/24/19 6:39 PM, Japheth Cleaver wrote:

On 7/24/2019 7:01 AM, Stephen Carville (xymon list) wrote:

On 7/23/19 9:08 AM, Japheth Cleaver wrote:

*********************************************************************

Just an FYI.? When I updated my CentOS 7 xymon server by building from
source, it refused to include the openssl libraries until I installed
the libtirpc-devel package.? Not sure why it is necessary.

Thanks, I'll make a note of that on the RPM site. The underlying reason
here is that GCC's rpc interface was removed after a long deprecation,
in favor of libtirpc. It was easier to simply test for that and move
forward on use. This will also be necessary for 4.4 (IPv6) and was the
main cause of the recent Fedora FTBFS's.

On Wed, Jul 24, 2019 at 06:46:51PM -0700, Japheth Cleaver wrote:

CSIRT may still have a write-up pending on these, but it is believed that
the only impact are segfaults when passed in invalid/overflow input. This is
typically a hostsvc being parsed and assigned to a PATH_MAX-sized variable
via sprintf rather than snprintf.

On Tue, Jul 23, 2019 at 08:57:49AM -0700, Japheth Cleaver wrote:

The specific CVEs in question are:
? CVE-2019-13451, CVE-2019-13452, CVE-2019-13455, CVE-2019-13473,

On 7/25/2019 6:24 AM, Axel Beckert wrote:

Hi Japheth,

On Tue, Jul 23, 2019 at 08:57:49AM -0700, Japheth Cleaver wrote:

The specific CVEs in question are:
 ? CVE-2019-13451, CVE-2019-13452, CVE-2019-13455, CVE-2019-13473,

But in the information for Xymon packagers you wrote a slightly
differing set of CVE-IDs:

The CVEs in question are:
     history.c (service overflows histlogfn) = CVE-2019-13451
     reportlog.c (service overflows histlogfn) = CVE-2019-13452
     csvinfo.c (srdb overflows dbfn) = CVE-2019-13273

     acknowledge.c (htmlquoted(hostname) overflows msgline) = CVE-2019-13455
     appfeed.c (htmlquoted(xymondreq) overflows errtxt) = CVE-2019-13484
     history.c (hostname overflows selfurl) = CVE-2019-13485
     svcstatus.c (htmlquoted(xymondreq) overflows errtxt) = CVE-2019-13486

Which ones are the correct ones? I used the latter ones in my
changelog entry for the Debian package.

		Kind regards, Axel

On 7/23/2019 9:08 AM, Japheth Cleaver wrote:

The RPMs available at Terabithia have been updated to 4.3.29-1 in the /testing/ repositories at the moment.

If no specific issues are found (please report!), I'll promote these into the production repo in a day or two. (An announcement will be made here.)

Please note that I've built these only for EL5/6/7/8 and F28+ at the moment. If there are requests for older RPM distributions, I can spin RPMs for them as well, but I'd like to begin pruning them a bit if they're not necessary.

Regards,
-jc


On 7/23/2019 8:57 AM, Japheth Cleaver wrote:

Hello all,

Xymon 4.3.29 has been released to Sourceforge and should be propagating to mirrors as I write this. Along with an assortment of bug fixes and compilation compatibility fixes for recent glibc systems, this version contains several fixes for security vulnerabilities within some CGI parsing. Although some of these overflows are not exploitable, others, including an XSS vulnerability are. Fixes beyond these CVEs have been made throughout the library, web, and network code to help reduce the likelihood of similar issues in other areas. As a result, all users are encouraged to upgrade.

The specific CVEs in question are:
? CVE-2019-13451, CVE-2019-13452, CVE-2019-13455, CVE-2019-13473,
? CVE-2019-13474, CVE-2019-13484, CVE-2019-13485, CVE-2019-13486

Henrik and I would like to extend our thanks to the University of Cambridge Computer Security
Incident Response Team, which reported the issues and helped validate their resolution.

Full release notes and other changes are available with the released tarball at https://sourceforge.net/projects/xymon/files/Xymon/4.3.29/

As always, thank you to everyone who has contributed patches, ideas, code, and feature requests to the project!


Sincerely,
Japheth "J.C." Cleaver

-----Original Message-----
From: Xymon <xymon-bounces at xymon.com> On Behalf Of Japheth Cleaver
Sent: Wednesday, July 24, 2019 7:40 PM
To: Stephen Carville (xymon list) <user-6ec031efcf79@xymon.invalid>; xymon at xymon.com
Subject: [EXT] Re: [Xymon] Xymon 4.3.29 Released - Important Security Update

On 7/24/2019 7:01 AM, Stephen Carville (xymon list) wrote:

On 7/23/19 9:08 AM, Japheth Cleaver wrote:

Lereta Email Checkpoint: External email. Please make sure you trust 
this source before clicking links or opening attachments.

*********************************************************************
*

Just an FYI.  When I updated my CentOS 7 xymon server by building from 
source, it refused to include the openssl libraries until I installed 
the libtirpc-devel package.  Not sure why it is necessary.

Thanks, I'll make a note of that on the RPM site. The underlying reason here is that GCC's rpc interface was removed after a long deprecation, in favor of libtirpc. It was easier to simply test for that and move forward on use. This will also be necessary for 4.4 (IPv6) and was the main cause of the recent Fedora FTBFS's.

wrote:

Japheth and Xymon 4.3.29 users,
     Attached is a context diff patch file for the Xymon 4.3.29 release to
address the following issues:

Bug Fixes:
- build/Makefile.Linux
   Use tirpc replacement only on glibc 2.26 and later.  This fixes
compiling and RPC issues on RHEL6 and RHEL7 platforms.

- lib/*.c files and xymonnet/xymonnet.c:
   Only use the "#pragma GCC diagnostic" options on gcc 4.5 and later.
This fixes compiling on RHEL6.


Enhancements:
- web/showgraph.c:
   Change underscore to space as this is a common mangling on temperature
and lic backends

- xymond/etcfiles/graphs.cfg and xymond/rrd/do_disk.c:
   Change disk sizes from KB to auto-scaling (i.e. GB, TB)
   Add FlexLM license graph for lic backend.

- xymond/rrd/do_temperature.c:
   - Strip off any bold and italic HTML tags on temperature sensor name


Thank you again for maintaining Xymon once again.  Please include my
recommend patches so the it compiles on RHEL6/7 platforms without issue.


Tom Schmidt
Sr Manager, IT, Product Engineering
IT ETD Eng Sites US
Micron Technology, Inc.

Micron Technology, Inc., Confidential and Proprietary.


-----Original Message-----
From: Xymon <xymon-bounces at xymon.com> On Behalf Of Japheth Cleaver
Sent: Wednesday, July 24, 2019 7:40 PM
To: Stephen Carville (xymon list) <user-6ec031efcf79@xymon.invalid>; xymon at xymon.com
Subject: [EXT] Re: [Xymon] Xymon 4.3.29 Released - Important Security
Update

On 7/24/2019 7:01 AM, Stephen Carville (xymon list) wrote:

On 7/23/19 9:08 AM, Japheth Cleaver wrote:

Lereta Email Checkpoint: External email. Please make sure you trust
this source before clicking links or opening attachments.

*********************************************************************
*

Just an FYI.  When I updated my CentOS 7 xymon server by building from
source, it refused to include the openssl libraries until I installed
the libtirpc-devel package.  Not sure why it is necessary.

Thanks, I'll make a note of that on the RPM site. The underlying reason
here is that GCC's rpc interface was removed after a long deprecation, in
favor of libtirpc. It was easier to simply test for that and move forward
on use. This will also be necessary for 4.4 (IPv6) and was the main cause
of the recent Fedora FTBFS's.


https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FChanges%2FSunRPCRemoval&data=user-e68b78a42832@xymon.invalid%7C5ba545ffc6bf46e2b2a508d710a109bd%7Cf38a5ecd28134862b11bac1d563c806f%7C0%7C0%7C636996156155520395&sdata=piP%2FSxXJ6rgvDb4Bea6PRKuxHE%2BPlAfvLehL0xGkZSw%3D&reserved=0

Regards,
-jc

On Fri, 2 Aug 2019 at 11:21, SebA <user-4631430d620a@xymon.invalid> wrote:

I'm not going to make any judgement on the merit of your patches, Tom, but
I did discover that you tried to get some of them merged some years ago and
Henrik rejected (some of) them:
https://lists.xymon.com/archive/2013-July/037941.html
However, he did say he merged one of the ones you're resubmitting, so
either it didn't actually get merged, or there's an issue with your e-mail
and/or patch.  From that e-mail in 2013:

* ./xymond/rrd/do_temperature.c

*>*      Strip leading bold and italic HTML tags from sensor names (seen
*>* on
*>* yellow and red alerts from BB tests)
• OK, applied.


I couldn't find any response from you to Henrik, but maybe it was private
or not in the following 2 months.

Kind regards,

SebA


On Thu, 1 Aug 2019 at 22:30, Tom Schmidt (tschmidt) <user-48d3fa8908d4@xymon.invalid>
wrote:

Japheth and Xymon 4.3.29 users,
     Attached is a context diff patch file for the Xymon 4.3.29 release
to address the following issues:

Bug Fixes:
- build/Makefile.Linux
   Use tirpc replacement only on glibc 2.26 and later.  This fixes
compiling and RPC issues on RHEL6 and RHEL7 platforms.

- lib/*.c files and xymonnet/xymonnet.c:
   Only use the "#pragma GCC diagnostic" options on gcc 4.5 and later.
This fixes compiling on RHEL6.


Enhancements:
- web/showgraph.c:
   Change underscore to space as this is a common mangling on temperature
and lic backends

- xymond/etcfiles/graphs.cfg and xymond/rrd/do_disk.c:
   Change disk sizes from KB to auto-scaling (i.e. GB, TB)
   Add FlexLM license graph for lic backend.

- xymond/rrd/do_temperature.c:
   - Strip off any bold and italic HTML tags on temperature sensor name


Thank you again for maintaining Xymon once again.  Please include my
recommend patches so the it compiles on RHEL6/7 platforms without issue.


Tom Schmidt
Sr Manager, IT, Product Engineering
IT ETD Eng Sites US
Micron Technology, Inc.
Office: +X (XXX) XXX-XXXX  Fax: (XXX)XXX-XXXX
Email: user-48d3fa8908d4@xymon.invalid  Website: micron.com
Micron Technology, Inc., Confidential and Proprietary.


-----Original Message-----
From: Xymon <xymon-bounces at xymon.com> On Behalf Of Japheth Cleaver
Sent: Wednesday, July 24, 2019 7:40 PM
To: Stephen Carville (xymon list) <user-6ec031efcf79@xymon.invalid>; xymon at xymon.com
Subject: [EXT] Re: [Xymon] Xymon 4.3.29 Released - Important Security
Update

On 7/24/2019 7:01 AM, Stephen Carville (xymon list) wrote:

On 7/23/19 9:08 AM, Japheth Cleaver wrote:

Lereta Email Checkpoint: External email. Please make sure you trust
this source before clicking links or opening attachments.

*********************************************************************
*

Just an FYI.  When I updated my CentOS 7 xymon server by building from
source, it refused to include the openssl libraries until I installed
the libtirpc-devel package.  Not sure why it is necessary.

Thanks, I'll make a note of that on the RPM site. The underlying reason
here is that GCC's rpc interface was removed after a long deprecation, in
favor of libtirpc. It was easier to simply test for that and move forward
on use. This will also be necessary for 4.4 (IPv6) and was the main cause
of the recent Fedora FTBFS's.


https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FChanges%2FSunRPCRemoval&data=user-e68b78a42832@xymon.invalid%7C5ba545ffc6bf46e2b2a508d710a109bd%7Cf38a5ecd28134862b11bac1d563c806f%7C0%7C0%7C636996156155520395&sdata=piP%2FSxXJ6rgvDb4Bea6PRKuxHE%2BPlAfvLehL0xGkZSw%3D&reserved=0

Regards,
-jc


https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.xymon.com%2Fmailman%2Flistinfo%2Fxymon&data=user-e68b78a42832@xymon.invalid%7C5ba545ffc6bf46e2b2a508d710a109bd%7Cf38a5ecd28134862b11bac1d563c806f%7C0%7C0%7C636996156155520395&sdata=Hdf4nWPmhqYAeZ7KL%2BB3ihwdbd%2FY2ZaA9tmYgY9PjE8%3D&reserved=0

Tom Schmidt
Sr Manager, IT, Product Engineering
IT ETD Eng Sites US
Micron Technology, Inc.
Office: +X (XXX) XXX-XXXX  Fax: (XXX)XXX-XXXX

Micron Technology, Inc., Confidential and Proprietary.


From: SebA <user-4631430d620a@xymon.invalid>
Sent: Friday, August 2, 2019 4:28 AM
To: Tom Schmidt (tschmidt) <user-48d3fa8908d4@xymon.invalid>
Cc: Japheth Cleaver <user-87556346d4af@xymon.invalid>; xymon at xymon.com
Subject: Re: [Xymon] [EXT] Re: Xymon 4.3.29 Released - Important Security Update

Tom,
Oh, did your patch to do_temperature.c get removed in r8050.  Looks like it might have done, but it's not obvious why.

Kind regards,

SebA


On Fri, 2 Aug 2019 at 11:21, SebA <user-4631430d620a@xymon.invalid<mailto:user-4631430d620a@xymon.invalid>> wrote:
I'm not going to make any judgement on the merit of your patches, Tom, but I did discover that you tried to get some of them merged some years ago and Henrik rejected (some of) them:

However, he did say he merged one of the ones you're resubmitting, so either it didn't actually get merged, or there's an issue with your e-mail and/or patch.  From that e-mail in 2013:

./xymond/rrd/do_temperature.c

     Strip leading bold and italic HTML tags from sensor names (seen

on

yellow and red alerts from BB tests)

OK, applied.

I couldn't find any response from you to Henrik, but maybe it was private or not in the following 2 months.

Kind regards,

SebA


On Thu, 1 Aug 2019 at 22:30, Tom Schmidt (tschmidt) <user-48d3fa8908d4@xymon.invalid<mailto:user-48d3fa8908d4@xymon.invalid>> wrote:
Japheth and Xymon 4.3.29 users,
     Attached is a context diff patch file for the Xymon 4.3.29 release to address the following issues:

Bug Fixes:
- build/Makefile.Linux
   Use tirpc replacement only on glibc 2.26 and later.  This fixes compiling and RPC issues on RHEL6 and RHEL7 platforms.

- lib/*.c files and xymonnet/xymonnet.c:
   Only use the "#pragma GCC diagnostic" options on gcc 4.5 and later. This fixes compiling on RHEL6.


Enhancements:
- web/showgraph.c:
   Change underscore to space as this is a common mangling on temperature and lic backends

- xymond/etcfiles/graphs.cfg and xymond/rrd/do_disk.c:
   Change disk sizes from KB to auto-scaling (i.e. GB, TB)
   Add FlexLM license graph for lic backend.

- xymond/rrd/do_temperature.c:
   - Strip off any bold and italic HTML tags on temperature sensor name


Thank you again for maintaining Xymon once again.  Please include my recommend patches so the it compiles on RHEL6/7 platforms without issue.


Tom Schmidt
Sr Manager, IT, Product Engineering
IT ETD Eng Sites US
Micron Technology, Inc.
Office: +X (XXX) XXX-XXXX  Fax: (XXX)XXX-XXXX

Micron Technology, Inc., Confidential and Proprietary.


-----Original Message-----
From: Xymon <xymon-bounces at xymon.com<mailto:xymon-bounces at xymon.com>> On Behalf Of Japheth Cleaver
Sent: Wednesday, July 24, 2019 7:40 PM
To: Stephen Carville (xymon list) <user-6ec031efcf79@xymon.invalid<mailto:user-6ec031efcf79@xymon.invalid>>; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: [EXT] Re: [Xymon] Xymon 4.3.29 Released - Important Security Update

On 7/24/2019 7:01 AM, Stephen Carville (xymon list) wrote:

On 7/23/19 9:08 AM, Japheth Cleaver wrote:

Lereta Email Checkpoint: External email. Please make sure you trust
this source before clicking links or opening attachments.

*********************************************************************
*

Just an FYI.  When I updated my CentOS 7 xymon server by building from
source, it refused to include the openssl libraries until I installed
the libtirpc-devel package.  Not sure why it is necessary.

Thanks, I'll make a note of that on the RPM site. The underlying reason here is that GCC's rpc interface was removed after a long deprecation, in favor of libtirpc. It was easier to simply test for that and move forward on use. This will also be necessary for 4.4 (IPv6) and was the main cause of the recent Fedora FTBFS's.

The Terabithia Xymon 4.3.29-1 packages have been updated in the production repositories and should be available for download at https://terabithia.org/rpms/xymon/

As a reminder, EL3 and EL4 and Fedora 18-27 have been retired -- those repos have been moved to the /retired/ directory.

As EPEL8 has not yet been released, an fping package is available in the EL8 repository, as well as man2html (needed for rebuilds).

-- 

On 8/5/2019 6:19 AM, Dirk Kastens wrote:

Hi,

I just upgraded our xymon server on Scientific Linux release 6.10 frpm xymon 4.3.28 to 4.3.29.

Two things are not working any longer:

http authentication: I defined the login information in the file /etc/xymon/netrc, which worked before the upgrade. Now the http test are red with the message "Authorization Required".

history files cannot be opened any more. When I click on the history button of a test, I get an empty page with the message "Cannot open history file"

-- 
Viele Gruesse,

Dirk Kastens
Universitaet Osnabrueck, Rechenzentrum (Computer Center)
Albrechtstr. 28, 49069 Osnabrueck, Germany
Tel.: +XX-XXX-XXX-XXXX, FAX: -2470

On Mon, 2019-08-05 at 07:52 -0700, Japheth Cleaver wrote:

On 8/5/2019 6:19 AM, Dirk Kastens wrote:

Hi,

I just upgraded our xymon server on Scientific Linux release 6.10 frpm
xymon 4.3.28 to 4.3.29.

Two things are not working any longer:

http authentication: I defined the login information in the file
/etc/xymon/netrc, which worked before the upgrade. Now the http test
are red with the message "Authorization Required".

history files cannot be opened any more. When I click on the history
button of a test, I get an empty page with the message "Cannot open
history file"

Thanks,

...

For history file checking, can you verify that hosts with dashes in the
name show this symptom while those with just alphanumerics (and periods)
don't? I believe this may actually be the bug cause here.

On Aug 5, 2019, at 11:51, John Horne <user-e95f1ec2f147@xymon.invalid> wrote:

On Mon, 2019-08-05 at 07:52 -0700, Japheth Cleaver wrote:

On 8/5/2019 6:19 AM, Dirk Kastens wrote:

Hi,

I just upgraded our xymon server on Scientific Linux release 6.10 frpm
xymon 4.3.28 to 4.3.29.

Two things are not working any longer:

http authentication: I defined the login information in the file
/etc/xymon/netrc, which worked before the upgrade. Now the http test
are red with the message "Authorization Required".

history files cannot be opened any more. When I click on the history
button of a test, I get an empty page with the message "Cannot open
history file"

Thanks,

...

For history file checking, can you verify that hosts with dashes in the
name show this symptom while those with just alphanumerics (and periods)
don't? I believe this may actually be the bug cause here.

Interesting. Can confirm that our clients without a hyphen/dash in the name
work fine with history. The hosts with a hyphen/dash do not - they get a
"Cannot open history file" error.


John.

--
John Horne | Senior Operations Analyst | Technology and Information Services
University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
[http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>;

This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.

From: Xymon <xymon-bounces at xymon.com> On Behalf Of Richard L. Hamilton
Sent: Monday, August 5, 2019 10:53 AM
To: xymon at xymon.com
Subject: [EXT] Re: [Xymon] Xymon 4.3.29 Released - Important Security Update

Yes, I'm seeing the dash problem too.  Some of my VMs have dashes in the name (since they don't migrate, it makes it easier to remember which host they're on); most don't run all the time ("dialup" if you will), but one (actually a Solaris zone) does.  All the ones with dashes in the name get "Cannot open history file".  Please fix!!!

On Aug 5, 2019, at 11:51, John Horne <user-e95f1ec2f147@xymon.invalid> wrote:

On Mon, 2019-08-05 at 07:52 -0700, Japheth Cleaver wrote:

On 8/5/2019 6:19 AM, Dirk Kastens wrote:

Hi,

I just upgraded our xymon server on Scientific Linux release 6.10 frpm xymon 4.3.28 to 4.3.29.

Two things are not working any longer:

http authentication: I defined the login information in the file /etc/xymon/netrc, which worked before the upgrade. Now the http test are red with the message "Authorization Required".

history files cannot be opened any more. When I click on the history button of a test, I get an empty page with the message "Cannot open history file"

Thanks,

...

For history file checking, can you verify that hosts with dashes in the name show this symptom while those with just alphanumerics (and periods) don't? I believe this may actually be the bug cause here.

Interesting. Can confirm that our clients without a hyphen/dash in the name work fine with history. The hosts with a hyphen/dash do not - they get a "Cannot open history file" error.


John.

--

From: Tom Schmidt (tschmidt) Sent: Monday, August 5, 2019 11:03 AM
To: Richard L. Hamilton <user-af55987f6d56@xymon.invalid>; xymon at xymon.com
Subject: RE: [EXT] Re: [Xymon] Xymon 4.3.29 Released - Important Security Update

I likewise see that history button issue for hostnames with dashes or underscores.  Attached is a context diff patch file to fix the issue.  Are there other alphanumerics in hostnames that should be added to line 608 of the web/history.c file?


Tom Schmidt
Sr Manager, IT, Product Engineering
IT ETD Eng Sites US
Micron Technology, Inc.
Office:?+X (XXX) XXX-XXXX ?Fax:?(208)368-2807
Email:?user-48d3fa8908d4@xymon.invalid? Website:?micron.com Micron Technology, Inc., Confidential and Proprietary.


-----Original Message-----
From: Xymon <xymon-bounces at xymon.com> On Behalf Of Richard L. Hamilton
Sent: Monday, August 5, 2019 10:53 AM
To: xymon at xymon.com
Subject: [EXT] Re: [Xymon] Xymon 4.3.29 Released - Important Security Update

Yes, I'm seeing the dash problem too.  Some of my VMs have dashes in the name (since they don't migrate, it makes it easier to remember which host they're on); most don't run all the time ("dialup" if you will), but one (actually a Solaris zone) does.  All the ones with dashes in the name get "Cannot open history file".  Please fix!!!

On Aug 5, 2019, at 11:51, John Horne <user-e95f1ec2f147@xymon.invalid> wrote:

On Mon, 2019-08-05 at 07:52 -0700, Japheth Cleaver wrote:

On 8/5/2019 6:19 AM, Dirk Kastens wrote:

Hi,

I just upgraded our xymon server on Scientific Linux release 6.10 frpm xymon 4.3.28 to 4.3.29.

Two things are not working any longer:

http authentication: I defined the login information in the file /etc/xymon/netrc, which worked before the upgrade. Now the http test are red with the message "Authorization Required".

history files cannot be opened any more. When I click on the history button of a test, I get an empty page with the message "Cannot open history file"

Thanks,

...

For history file checking, can you verify that hosts with dashes in the name show this symptom while those with just alphanumerics (and
periods) don't? I believe this may actually be the bug cause here.

Interesting. Can confirm that our clients without a hyphen/dash in the name work fine with history. The hosts with a hyphen/dash do not - they get a "Cannot open history file" error.


John.

--
John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon |
PL4 8AA | UK ________________________________ [https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
plymouth.ac.uk%2Fimages%2Femail_footer.gif&data=02%7C01%7Ctschmidt
%40micron.com%7Cad7b0f57ffe848cc8adf08d719c564d8%7Cf38a5ecd28134862b11
bac1d563c806f%7C0%7C0%7C637006207919043258&sdata=PU9uQpCzE4ncJnmC9
GDVRFV7n9silwy1FQP3IyCYMNk%3D&amp;reserved=0]<https://nam01.safelinks.
protection.outlook.com/?url=http%3A%2F%2Fwww.plymouth.ac.uk%2Fworldcla
ss&amp;data=user-e68b78a42832@xymon.invalid%7Cad7b0f57ffe848cc8adf08d7
19c564d8%7Cf38a5ecd28134862b11bac1d563c806f%7C0%7C0%7C6370062079190432
58&amp;sdata=%2BkT7Ki%2FfHy2o96Tf2Z483xvGh2UUxEauM%2BJHcv5uK0k%3D&amp;
reserved=0>

This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.

https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
.xymon.com%2Fmailman%2Flistinfo%2Fxymon&amp;data=02%7C01%7Ctschmidt%40
micron.com%7Cad7b0f57ffe848cc8adf08d719c564d8%7Cf38a5ecd28134862b11bac
1d563c806f%7C0%7C0%7C637006207919043258&amp;sdata=0jIe1wKKWphh7%2FFhir
dYAB8Z8A4Qwbr%2BKIKcOdV5kMA%3D&amp;reserved=0

On 8/5/2019 10:54 AM, Tom Schmidt (tschmidt) wrote:

I looked at the source code of 4.3.29 for more instances where dashes in the hostname was not being accepted.  I found that the web/reportlog.c file also needed patched to allow dashes and underscores in hostnames and service names for the "Availability Report" feature.  Attached is the patch file for it as well.


Tom Schmidt
Sr Manager, IT, Product Engineering
IT ETD Eng Sites US
Micron Technology, Inc.
Office:?+X (XXX) XXX-XXXX ?Fax:?(208)368-2807
Email:?user-48d3fa8908d4@xymon.invalid? Website:?micron.com
Micron Technology, Inc., Confidential and Proprietary.


-----Original Message-----
From: Tom Schmidt (tschmidt)
Sent: Monday, August 5, 2019 11:03 AM
To: Richard L. Hamilton <user-af55987f6d56@xymon.invalid>; xymon at xymon.com
Subject: RE: [EXT] Re: [Xymon] Xymon 4.3.29 Released - Important Security Update

I likewise see that history button issue for hostnames with dashes or underscores.  Attached is a context diff patch file to fix the issue.  Are there other alphanumerics in hostnames that should be added to line 608 of the web/history.c file?


Tom Schmidt
Sr Manager, IT, Product Engineering
IT ETD Eng Sites US
Micron Technology, Inc.
Office:?+X (XXX) XXX-XXXX ?Fax:?(208)368-2807
Email:?user-48d3fa8908d4@xymon.invalid? Website:?micron.com Micron Technology, Inc., Confidential and Proprietary.


-----Original Message-----
From: Xymon <xymon-bounces at xymon.com> On Behalf Of Richard L. Hamilton
Sent: Monday, August 5, 2019 10:53 AM
To: xymon at xymon.com
Subject: [EXT] Re: [Xymon] Xymon 4.3.29 Released - Important Security Update

Yes, I'm seeing the dash problem too.  Some of my VMs have dashes in the name (since they don't migrate, it makes it easier to remember which host they're on); most don't run all the time ("dialup" if you will), but one (actually a Solaris zone) does.  All the ones with dashes in the name get "Cannot open history file".  Please fix!!!

On Aug 5, 2019, at 11:51, John Horne <user-e95f1ec2f147@xymon.invalid> wrote:

On Mon, 2019-08-05 at 07:52 -0700, Japheth Cleaver wrote:

On 8/5/2019 6:19 AM, Dirk Kastens wrote:

Hi,

I just upgraded our xymon server on Scientific Linux release 6.10
frpm xymon 4.3.28 to 4.3.29.

Two things are not working any longer:

http authentication: I defined the login information in the file
/etc/xymon/netrc, which worked before the upgrade. Now the http test
are red with the message "Authorization Required".

history files cannot be opened any more. When I click on the history
button of a test, I get an empty page with the message "Cannot open
history file"

Thanks,

...

For history file checking, can you verify that hosts with dashes in
the name show this symptom while those with just alphanumerics (and
periods) don't? I believe this may actually be the bug cause here.

Interesting. Can confirm that our clients without a hyphen/dash in the
name work fine with history. The hosts with a hyphen/dash do not -
they get a "Cannot open history file" error.


John.

On Aug 5, 2019, at 16:26, Japheth Cleaver <user-87556346d4af@xymon.invalid> wrote:

Thanks, this does indeed fix the issue. I've added in underscores (which have been valid for hostnames in xymon, though not in reality) to match the checks elsewhere. Would appreciate if others could confirm on this.

Fix/patch is committed in https://sourceforge.net/p/xymon/code/8072/ ; 4.3.30 with this to come shortly.

Regards,
-jc

On 8/5/2019 10:54 AM, Tom Schmidt (tschmidt) wrote:

I looked at the source code of 4.3.29 for more instances where dashes in the hostname was not being accepted.  I found that the web/reportlog.c file also needed patched to allow dashes and underscores in hostnames and service names for the "Availability Report" feature.  Attached is the patch file for it as well.


Tom Schmidt
Sr Manager, IT, Product Engineering
IT ETD Eng Sites US
Micron Technology, Inc.
Office: +X (XXX) XXX-XXXX  Fax: (XXX)XXX-XXXX
Email: user-48d3fa8908d4@xymon.invalid  Website: micron.com
Micron Technology, Inc., Confidential and Proprietary.


-----Original Message-----
From: Tom Schmidt (tschmidt)
Sent: Monday, August 5, 2019 11:03 AM
To: Richard L. Hamilton <user-af55987f6d56@xymon.invalid>; xymon at xymon.com
Subject: RE: [EXT] Re: [Xymon] Xymon 4.3.29 Released - Important Security Update

I likewise see that history button issue for hostnames with dashes or underscores.  Attached is a context diff patch file to fix the issue.  Are there other alphanumerics in hostnames that should be added to line 608 of the web/history.c file?


Tom Schmidt
Sr Manager, IT, Product Engineering
IT ETD Eng Sites US
Micron Technology, Inc.
Office: +X (XXX) XXX-XXXX  Fax: (XXX)XXX-XXXX
Email: user-48d3fa8908d4@xymon.invalid  Website: micron.com Micron Technology, Inc., Confidential and Proprietary.


-----Original Message-----
From: Xymon <xymon-bounces at xymon.com> On Behalf Of Richard L. Hamilton
Sent: Monday, August 5, 2019 10:53 AM
To: xymon at xymon.com
Subject: [EXT] Re: [Xymon] Xymon 4.3.29 Released - Important Security Update

Yes, I'm seeing the dash problem too.  Some of my VMs have dashes in the name (since they don't migrate, it makes it easier to remember which host they're on); most don't run all the time ("dialup" if you will), but one (actually a Solaris zone) does.  All the ones with dashes in the name get "Cannot open history file".  Please fix!!!

On Aug 5, 2019, at 11:51, John Horne <user-e95f1ec2f147@xymon.invalid> wrote:

On Mon, 2019-08-05 at 07:52 -0700, Japheth Cleaver wrote:

On 8/5/2019 6:19 AM, Dirk Kastens wrote:

Hi,

I just upgraded our xymon server on Scientific Linux release 6.10
frpm xymon 4.3.28 to 4.3.29.

Two things are not working any longer:

http authentication: I defined the login information in the file
/etc/xymon/netrc, which worked before the upgrade. Now the http test
are red with the message "Authorization Required".

history files cannot be opened any more. When I click on the history
button of a test, I get an empty page with the message "Cannot open
history file"

Thanks,

...

For history file checking, can you verify that hosts with dashes in
the name show this symptom while those with just alphanumerics (and
periods) don't? I believe this may actually be the bug cause here.

Interesting. Can confirm that our clients without a hyphen/dash in the
name work fine with history. The hosts with a hyphen/dash do not -
they get a "Cannot open history file" error.


John.

On 8/5/2019 1:21 PM, Richard L. Hamilton wrote:

Seems to me that underscore is mainly a problem with address 0.0.0.0 in hosts.cfg (name to IP address resolution via host naming services, esp. if that ends up being DNS). If an IP address in hosts.cfg is used, and the hostname there isn't used in some other way, I don't guess it would matter.

Either a reminder in documentation (including in the hosts.cfg.5.html file) or a check and warning in case a name with underscore was used with non hosts.cfg resolution would probably keep people out of trouble; although underscores are wrong, they're widely tolerated in non-DNS hostnames, so I can see allowing them when they wouldn't cause further problems.

On Mon, Aug 05, 2019 at 05:21:33PM -0400, Richard L. Hamilton wrote:

Seems to me that underscore is mainly a problem with address 0.0.0.0
in hosts.cfg (name to IP address resolution via host naming
services, esp. if that ends up being DNS). If an IP address in
hosts.cfg is used, and the hostname there isn't used in some other
way, I don't guess it would matter.

			Kind regards, Axel
-- 
PGP: 2FF9CD59612616B5      /~\  Plain Text Ribbon Campaign, http://arc.pasp.de/
Mail: user-bc188e45dae4@xymon.invalid  \ /  Say No to HTML in E-Mail and Usenet
Mail+Jabber: user-0064bde8d49d@xymon.invalid  X
https://axel.beckert.ch/   / \  I love long mails: https://email.is-not-s.ms/

On Aug 5, 2019, at 17:38, John Thurston <user-ce4d79d99bab@xymon.invalid> wrote:

Hang on. I don't think there is any prohibition on hostnames with underscores. There is a prohibition for *A Records* with underscores, but the character remains valid for use in other record types.

A *hostname* of foo_1.bar.com is legal. It just can't be defined in a zone file as:
 foo_1.bar.com.  A  10.11.12.13

but it could be defined as:
 foo_1.bar.com.  CNAME  baz.bar.com.
 baz.bar.com.    A  10.11.12.13

To a resolving client, the end result is the same (a name gets turned into an address).

And I sure hope xymon would correctly handle a line in hosts.cfg
0.0.0.0  foo_1.bar.com  #


--
  Do things because you should, not just because you can.

John Thurston    XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Department of Administration
State of Alaska

On 8/5/2019 1:21 PM, Richard L. Hamilton wrote:

Seems to me that underscore is mainly a problem with address 0.0.0.0 in hosts.cfg (name to IP address resolution via host naming services, esp. if that ends up being DNS). If an IP address in hosts.cfg is used, and the hostname there isn't used in some other way, I don't guess it would matter.
Either a reminder in documentation (including in the hosts.cfg.5.html file) or a check and warning in case a name with underscore was used with non hosts.cfg resolution would probably keep people out of trouble; although underscores are wrong, they're widely tolerated in non-DNS hostnames, so I can see allowing them when they wouldn't cause further problems.

From: Xymon <xymon-bounces at xymon.com> On Behalf Of Axel Beckert
Sent: Monday, August 5, 2019 3:48 PM
To: xymon at xymon.com
Subject: [EXT] Re: [Xymon] Hostname validation (was Re: Xymon 4.3.29 Released - Important Security Update)

Hi,

On Mon, Aug 05, 2019 at 05:21:33PM -0400, Richard L. Hamilton wrote:

Seems to me that underscore is mainly a problem with address 0.0.0.0 
in hosts.cfg (name to IP address resolution via host naming services, 
esp. if that ends up being DNS). If an IP address in hosts.cfg is 
used, and the hostname there isn't used in some other way, I don't 
guess it would matter.

Hmmm, indeed

as well as RFC 608, 810 and 952 say that no other characters than letters, digits and hyphens are allowed.

I'm though quite sure to already have seen hostnames with underscore and even a slash in the wild. The latter was though about 20 years ago or so where I saw router names of a university with a slash in their hostname.

Traces of hostnames with slashes can also be found on the web, e.g.

So IMHO while not being standard-compliant hostnames, Xymon should accept at least hostnames with underscore, too.

On the other hand, I don't think, it's necessary to also add the slash to the list of valid characters for hostnames as the dot is already in there, too, and hostnames which are allowed to contain "/../" are definitely no good. :-)

			Kind regards, Axel
-- 

Mail: user-bc188e45dae4@xymon.invalid  \ /  Say No to HTML in E-Mail and Usenet
Mail+Jabber: user-0064bde8d49d@xymon.invalid  X

On 8/5/2019 4:04 PM, Tom Schmidt (tschmidt) wrote:

I did not mean for this to get into a debate.  The systems I am monitoring with Xymon do not have underscores in their hostnames but many have the hyphen.  When I queried my companies DNS server, a few CNAME records have underscores, but no A records have an underscore.  Xymon could monitor a system using a CNAME record, so IMHO it should still allow it for the reporting and history features.


Tom Schmidt
Sr Manager, IT, Product Engineering
IT ETD Eng Sites US
Micron Technology, Inc.
Office:?+X (XXX) XXX-XXXX ?Fax:?(208)368-2807
Email:?user-48d3fa8908d4@xymon.invalid? Website:?micron.com
Micron Technology, Inc., Confidential and Proprietary.


-----Original Message-----
From: Xymon <xymon-bounces at xymon.com> On Behalf Of Axel Beckert
Sent: Monday, August 5, 2019 3:48 PM
To: xymon at xymon.com
Subject: [EXT] Re: [Xymon] Hostname validation (was Re: Xymon 4.3.29 Released - Important Security Update)

Hi,

On Mon, Aug 05, 2019 at 05:21:33PM -0400, Richard L. Hamilton wrote:

Seems to me that underscore is mainly a problem with address 0.0.0.0
in hosts.cfg (name to IP address resolution via host naming services,
esp. if that ends up being DNS). If an IP address in hosts.cfg is
used, and the hostname there isn't used in some other way, I don't
guess it would matter.

Hmmm, indeed
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDomain_Name_System%23Domain_name_syntax%2C_internationalization&data=user-e68b78a42832@xymon.invalid%7C7bdb890c737b4e9b908708d719eea31b%7Cf38a5ecd28134862b11bac1d563c806f%7C0%7C0%7C637006385051444790&sdata=Uo0pyo9e0AkeTihN9nPvLDW%2BizoaHNpp%2BCEuIFBkcVI%3D&reserved=0
as well as RFC 608, 810 and 952 say that no other characters than letters, digits and hyphens are allowed.

I'm though quite sure to already have seen hostnames with underscore and even a slash in the wild. The latter was though about 20 years ago or so where I saw router names of a university with a slash in their hostname.

Traces of hostnames with slashes can also be found on the web, e.g.
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserverfault.com%2Fquestions%2F963735%2Fsyslog-ng-hostnames-with-slashes&data=user-e68b78a42832@xymon.invalid%7C7bdb890c737b4e9b908708d719eea31b%7Cf38a5ecd28134862b11bac1d563c806f%7C0%7C0%7C637006385051444790&sdata=YCiH8mRaATsBxF8w9APxCcYMdi81zSz1tzD2JnhWkZY%3D&reserved=0

And underscore is explicitly mentioned in
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHostname%23Restrictions_on_valid_hostnames&data=user-e68b78a42832@xymon.invalid%7C7bdb890c737b4e9b908708d719eea31b%7Cf38a5ecd28134862b11bac1d563c806f%7C0%7C0%7C637006385051444790&sdata=2TieCKA%2F1VVIIEMVdm7A3hU5q2CDggPp0b2R%2B9iEzhE%3D&reserved=0

So IMHO while not being standard-compliant hostnames, Xymon should accept at least hostnames with underscore, too.

On the other hand, I don't think, it's necessary to also add the slash to the list of valid characters for hostnames as the dot is already in there, too, and hostnames which are allowed to contain "/../" are definitely no good. :-)

			Kind regards, Axel

On Tue, 6 Aug 2019 at 08:52, Richard L. Hamilton <user-af55987f6d56@xymon.invalid> wrote:

You're probably right...but that's just sick, using a CNAME to make an end
run around the A record restriction. :-)

On Aug 5, 2019, at 17:38, John Thurston <user-ce4d79d99bab@xymon.invalid>
wrote:

Hang on. I don't think there is any prohibition on hostnames with
underscores. There is a prohibition for *A Records* with underscores, but
the character remains valid for use in other record types.

A *hostname* of foo_1.bar.com is legal. It just can't be defined in a
zone file as:
 foo_1.bar.com.  A  10.11.12.13

but it could be defined as:
 foo_1.bar.com.  CNAME  baz.bar.com.
 baz.bar.com.    A  10.11.12.13

To a resolving client, the end result is the same (a name gets turned
into an address).

And I sure hope xymon would correctly handle a line in hosts.cfg
0.0.0.0  foo_1.bar.com  #


--
  Do things because you should, not just because you can.

John Thurston    XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Department of Administration
State of Alaska

On 8/5/2019 1:21 PM, Richard L. Hamilton wrote:

Seems to me that underscore is mainly a problem with address 0.0.0.0 in
hosts.cfg (name to IP address resolution via host naming services, esp. if
that ends up being DNS). If an IP address in hosts.cfg is used, and the
hostname there isn't used in some other way, I don't guess it would matter.
Either a reminder in documentation (including in the hosts.cfg.5.html
file) or a check and warning in case a name with underscore was used with
non hosts.cfg resolution would probably keep people out of trouble;
although underscores are wrong, they're widely tolerated in non-DNS
hostnames, so I can see allowing them when they wouldn't cause further
problems.

On Mon, 2019-08-05 at 13:26 -0700, Japheth Cleaver wrote:

Thanks, this does indeed fix the issue. I've added in underscores (which
have been valid for hostnames in xymon, though not in reality) to match
the checks elsewhere. Would appreciate if others could confirm on this.

Fix/patch is committed in https://sourceforge.net/p/xymon/code/8072/ ;
4.3.30 with this to come shortly.

John.

--
John Horne | Senior Operations Analyst | Technology and Information Services
University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
[http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>;

This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.

From: Xymon <xymon-bounces at xymon.com> On Behalf Of John Horne
Sent: Thursday, August 8, 2019 10:16 AM
To: xymon at xymon.com
Subject: [EXT] Re: [Xymon] Hostname validation (was Re: Xymon 4.3.29 Released - Important Security Update)

On Mon, 2019-08-05 at 13:26 -0700, Japheth Cleaver wrote:

Thanks, this does indeed fix the issue. I've added in underscores 
(which have been valid for hostnames in xymon, though not in reality) 
to match the checks elsewhere. Would appreciate if others could confirm on this.

Fix/patch is committed in 

4.3.30 with this to come shortly.

Sorry - stealing the subject - could I ask to hold fire with 4.3.30 for a little while. There still seems to be a problem with graph titles when using 'exec:'. I'm just trying to track it down now (looks like an extra double-quote has crept in somewhere). Thanks.


John.

--

This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.

On 8/5/19 6:19 AM, Dirk Kastens wrote:

Hi,

I just upgraded our xymon server on Scientific Linux release 6.10 frpm xymon 4.3.28 to 4.3.29.

Two things are not working any longer:

http authentication: I defined the login information in the file /etc/xymon/netrc, which worked before the upgrade. Now the http test are red with the message "Authorization 
Required".

history files cannot be opened any more. When I click on the history button of a test, I get an empty page with the message "Cannot open history file"

Am 29.07.2019 um 19:41 schrieb Japheth Cleaver:

The Terabithia Xymon 4.3.29-1 packages have been updated in the production repositories and should be available for download at https://terabithia.org/rpms/xymon/

As a reminder, EL3 and EL4 and Fedora 18-27 have been retired -- those repos have been moved to the /retired/ directory.

As EPEL8 has not yet been released, an fping package is available in the EL8 repository, as well as man2html (needed for rebuilds).

On Fri, Aug 9, 2019, 12:15 AM Bruce Ferrell <user-24fbf1912cfe@xymon.invalid> wrote:

I did the same thing and did it from source.

After removing the #pragma statements and adding libtirpc-devel to get it
to compile, I found the https sites failed.  They do pass the sslcert test.

I just rolled back to 4.3.28

I'll figure it out later, after I figure out how the rollback screwed up
the built in SNMP support that I so painfully got working and was still
documenting.

sigh


On 8/5/19 6:19 AM, Dirk Kastens wrote:

Hi,

I just upgraded our xymon server on Scientific Linux release 6.10 frpm
xymon 4.3.28 to 4.3.29.

Two things are not working any longer:

http authentication: I defined the login information in the file

/etc/xymon/netrc, which worked before the upgrade. Now the http test are
red with the message "Authorization

Required".

history files cannot be opened any more. When I click on the history
button of a test, I get an empty page with the message "Cannot open history
file"

Am 29.07.2019 um 19:41 schrieb Japheth Cleaver:

The Terabithia Xymon 4.3.29-1 packages have been updated in the
production repositories and should be available for download at
https://terabithia.org/rpms/xymon/

As a reminder, EL3 and EL4 and Fedora 18-27 have been retired -- those
repos have been moved to the /retired/ directory.

As EPEL8 has not yet been released, an fping package is available in
the EL8 repository, as well as man2html (needed for rebuilds).

On Aug 9, 2019, at 09:23, Robert Herron <user-8b27ea4290da@xymon.invalid> wrote:

I had a similar issue with the HTTPS test. I found specifying the Xymon server's IP during the configure script caused the problem. The OpenSSL info didn't show up on the xymonnet page.  Rerunning configure, leaving 127.0.0.1 for the IP, rebuilding, and reinstalling fixed it. 
I still had other issues so I reverted my test server back to 4.3.28 since I was leaving for vacation. 
Running on Oracle Linux 6.x, used the patches available thru last Friday but don't recall if libtirpc-devel is installed. 


On Fri, Aug 9, 2019, 12:15 AM Bruce Ferrell <user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>> wrote:

I did the same thing and did it from source.

After removing the #pragma statements and adding libtirpc-devel to get it to compile, I found the https sites failed.  They do pass the sslcert test.

I just rolled back to 4.3.28

I'll figure it out later, after I figure out how the rollback screwed up the built in SNMP support that I so painfully got working and was still documenting.

sigh


On 8/5/19 6:19 AM, Dirk Kastens wrote:

Hi,

I just upgraded our xymon server on Scientific Linux release 6.10 frpm xymon 4.3.28 to 4.3.29.

Two things are not working any longer:

http authentication: I defined the login information in the file /etc/xymon/netrc, which worked before the upgrade. Now the http test are red with the message "Authorization > Required".

history files cannot be opened any more. When I click on the history button of a test, I get an empty page with the message "Cannot open history file"

Am 29.07.2019 um 19:41 schrieb Japheth Cleaver:

The Terabithia Xymon 4.3.29-1 packages have been updated in the production repositories and should be available for download at https://terabithia.org/rpms/xymon/ <https://terabithia.org/rpms/xymon/>;

As a reminder, EL3 and EL4 and Fedora 18-27 have been retired -- those repos have been moved to the /retired/ directory.

As EPEL8 has not yet been released, an fping package is available in the EL8 repository, as well as man2html (needed for rebuilds).

From: Tom Schmidt (tschmidt) 
Sent: Thursday, August 8, 2019 10:54 AM
To: John Horne <user-e95f1ec2f147@xymon.invalid>; xymon at xymon.com
Subject: Re: [Xymon] Hostname validation (was Re: Xymon 4.3.29 Released - Important Security Update)

I likewise see one more issue with 4.3.29 that I am trying to correct.  The xymonnet RPC check is not displaying the RPC test summary correctly at the top of the svcstatus report.  It should look like this:

	Mon Apr 1 10:53:02 2019 rpc ok,

	green Service rpcbind (ID: 100000) found on port 111
	green Service ypbind (ID: 100007) found on port 1013

	Command: rpcinfo -p 1.2.3.4 2>&1

Instead, it is getting truncated like this:

	Thu Aug 8 10:42:07 2019 rpc ok,

	green S

	Command: rpcinfo -p 1.2.3.4 2>&1

The truncation is causing any red/yellow/green RPC checks to not show properly at the top of the svcstatus report.


Tom Schmidt
Sr Manager, IT, Product Engineering
IT ETD Eng Sites US
Micron Technology, Inc.
Office:?+X (XXX) XXX-XXXX ?Fax:?(208)368-2807
Email:?user-48d3fa8908d4@xymon.invalid? Website:?micron.com Micron Technology, Inc., Confidential and Proprietary.


-----Original Message-----
From: Xymon <xymon-bounces at xymon.com> On Behalf Of John Horne
Sent: Thursday, August 8, 2019 10:16 AM
To: xymon at xymon.com
Subject: [EXT] Re: [Xymon] Hostname validation (was Re: Xymon 4.3.29 Released - Important Security Update)

On Mon, 2019-08-05 at 13:26 -0700, Japheth Cleaver wrote:

Thanks, this does indeed fix the issue. I've added in underscores 
(which have been valid for hostnames in xymon, though not in reality) 
to match the checks elsewhere. Would appreciate if others could confirm on this.

Fix/patch is committed in
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour
ceforge.net%2Fp%2Fxymon%2Fcode%2F8072%2F&data=02%7C01%7Ctschmidt%4
0micron.com%7C64388b4a70ef471166d708d71c1bcbf8%7Cf38a5ecd28134862b11ba
c1d563c806f%7C0%7C0%7C637008778033157428&sdata=L9XY5CBlGUlIFZDQpaO
kV0nffOL4RDS0uIN%2F6uJELFc%3D&reserved=0 ;
4.3.30 with this to come shortly.

Sorry - stealing the subject - could I ask to hold fire with 4.3.30 for a little while. There still seems to be a problem with graph titles when using 'exec:'. I'm just trying to track it down now (looks like an extra double-quote has crept in somewhere). Thanks.


John.

--
John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK ________________________________ [https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.plymouth.ac.uk%2Fimages%2Femail_footer.gif&amp;data=user-e68b78a42832@xymon.invalid%7C64388b4a70ef471166d708d71c1bcbf8%7Cf38a5ecd28134862b11bac1d563c806f%7C0%7C0%7C637008778033157428&amp;sdata=Vbz%2F5ikN5U4HsRz6X5qm3dEAyDM9sMmdrY1%2FT%2FgFIYM%3D&amp;reserved=0]<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.plymouth.ac.uk%2Fworldclass&amp;data=user-e68b78a42832@xymon.invalid%7C64388b4a70ef471166d708d71c1bcbf8%7Cf38a5ecd28134862b11bac1d563c806f%7C0%7C0%7C637008778033167417&amp;sdata=WYuWzp6kfIUgQzeedzE21f8kcremFyHPGj%2FiJNG038k%3D&amp;reserved=0>;

This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.

On 8/9/2019 7:47 AM, Richard L. Hamilton wrote:

I think I had to add login and password to the URL for an http test (to something that required those), where previously an entry in $HOME/server/etc/netrc sufficed. ?In other words, the behavior changed with the update.

On Aug 9, 2019, at 09:23, Robert Herron <user-8b27ea4290da@xymon.invalid <mailto:user-8b27ea4290da@xymon.invalid>> wrote:

I had a similar issue with the HTTPS test. I found specifying the Xymon server's IP during the configure script caused the problem. The OpenSSL info didn't show up on the xymonnet page.? Rerunning configure, leaving 127.0.0.1 for the IP, rebuilding, and reinstalling fixed it.

I still had other issues so I reverted my test server back to 4.3.28 since I was leaving for vacation.

Running on Oracle Linux 6.x, used the patches available thru last Friday but don't recall if libtirpc-devel is installed.


On Fri, Aug 9, 2019, 12:15 AM Bruce Ferrell <user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>> wrote:


    I did the same thing and did it from source.

    After removing the #pragma statements and adding libtirpc-devel
    to get it to compile, I found the https sites failed.? They do
    pass the sslcert test.

    I just rolled back to 4.3.28

    I'll figure it out later, after I figure out how the rollback
    screwed up the built in SNMP support that I so painfully got
    working and was still documenting.

    sigh


    On 8/5/19 6:19 AM, Dirk Kastens wrote:

Hi,

I just upgraded our xymon server on Scientific Linux release

    6.10 frpm xymon 4.3.28 to 4.3.29.

Two things are not working any longer:

http authentication: I defined the login information in the
    file /etc/xymon/netrc, which worked before the upgrade. Now the
    http test are red with the message "Authorization
Required".

history files cannot be opened any more. When I click on the
    history button of a test, I get an empty page with the message

    "Cannot open history file"

Am 29.07.2019 um 19:41 schrieb Japheth Cleaver:

The Terabithia Xymon 4.3.29-1 packages have been updated in
    the production repositories and should be available for download
    at https://terabithia.org/rpms/xymon/

As a reminder, EL3 and EL4 and Fedora 18-27 have been retired

    -- those repos have been moved to the /retired/ directory.

As EPEL8 has not yet been released, an fping package is
    available in the EL8 repository, as well as man2html (needed for
    rebuilds).

wrote:

Richard:
Can you provide the output of --debug on a xymonnet run off-list? This
could be a parsing issue somewhere, but from glancing at the code I'm not
sure where the logic might be diverging.

Robert:

So far I haven't been able to duplicate this one. Do you happen to have
./configure output in scrollback? While an IP that doesn't match hostname
or isn't up *could* affect something, the compilation check for SSL support
seems totally distinct. Were other SSL tests also failing? Alternatively,
is there a chance the SSL versioning/cypher lockdown might be different on
this endpoint?

-jc


On 8/9/2019 7:47 AM, Richard L. Hamilton wrote:

I think I had to add login and password to the URL for an http test (to
something that required those), where previously an entry in
$HOME/server/etc/netrc sufficed.  In other words, the behavior changed with
the update.

On Aug 9, 2019, at 09:23, Robert Herron <user-8b27ea4290da@xymon.invalid> wrote:

I had a similar issue with the HTTPS test. I found specifying the Xymon
server's IP during the configure script caused the problem. The OpenSSL
info didn't show up on the xymonnet page.  Rerunning configure, leaving
127.0.0.1 for the IP, rebuilding, and reinstalling fixed it.

I still had other issues so I reverted my test server back to 4.3.28 since
I was leaving for vacation.

Running on Oracle Linux 6.x, used the patches available thru last Friday
but don't recall if libtirpc-devel is installed.


On Fri, Aug 9, 2019, 12:15 AM Bruce Ferrell <user-24fbf1912cfe@xymon.invalid> wrote:

I did the same thing and did it from source.

After removing the #pragma statements and adding libtirpc-devel to get it
to compile, I found the https sites failed.  They do pass the sslcert test.

I just rolled back to 4.3.28

I'll figure it out later, after I figure out how the rollback screwed up
the built in SNMP support that I so painfully got working and was still
documenting.

sigh


On 8/5/19 6:19 AM, Dirk Kastens wrote:

Hi,

I just upgraded our xymon server on Scientific Linux release 6.10 frpm
xymon 4.3.28 to 4.3.29.

Two things are not working any longer:

http authentication: I defined the login information in the file

/etc/xymon/netrc, which worked before the upgrade. Now the http test are
red with the message "Authorization

Required".

history files cannot be opened any more. When I click on the history
button of a test, I get an empty page with the message "Cannot open history
file"

Am 29.07.2019 um 19:41 schrieb Japheth Cleaver:

The Terabithia Xymon 4.3.29-1 packages have been updated in the
production repositories and should be available for download at
https://terabithia.org/rpms/xymon/

As a reminder, EL3 and EL4 and Fedora 18-27 have been retired -- those
repos have been moved to the /retired/ directory.

As EPEL8 has not yet been released, an fping package is available in
the EL8 repository, as well as man2html (needed for rebuilds).