Xymon 4.3.29 Released - Important Security Update
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:?+1 (208) 368-4058 ?Fax:?(208)368-2807 Email:?tschmidt at micron.com? 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 <rlhamil2 at gmail.com>; 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:?+1 (208) 368-4058 ?Fax:?(208)368-2807 Email:?tschmidt at micron.com? 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 <john.horne at plymouth.ac.uk> 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&reserved=0]<https://nam01.safelinks. protection.outlook.com/?url=http%3A%2F%2Fwww.plymouth.ac.uk%2Fworldcla ss&data=02%7C01%7Ctschmidt%40micron.com%7Cad7b0f57ffe848cc8adf08d7 19c564d8%7Cf38a5ecd28134862b11bac1d563c806f%7C0%7C0%7C6370062079190432 58&sdata=%2BkT7Ki%2FfHy2o96Tf2Z483xvGh2UUxEauM%2BJHcv5uK0k%3D& 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.
Xymon mailing list Xymon at xymon.com https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists .xymon.com%2Fmailman%2Flistinfo%2Fxymon&data=02%7C01%7Ctschmidt%40 micron.com%7Cad7b0f57ffe848cc8adf08d719c564d8%7Cf38a5ecd28134862b11bac 1d563c806f%7C0%7C0%7C637006207919043258&sdata=0jIe1wKKWphh7%2FFhir dYAB8Z8A4Qwbr%2BKIKcOdV5kMA%3D&reserved=0
Xymon mailing list Xymon at xymon.com https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.xymon.com%2Fmailman%2Flistinfo%2Fxymon&data=02%7C01%7Ctschmidt%40micron.com%7Cad7b0f57ffe848cc8adf08d719c564d8%7Cf38a5ecd28134862b11bac1d563c806f%7C0%7C0%7C637006207919043258&sdata=0jIe1wKKWphh7%2FFhirdYAB8Z8A4Qwbr%2BKIKcOdV5kMA%3D&reserved=0
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:?+1 (208) 368-4058 ?Fax:?(208)368-2807 Email:?tschmidt at micron.com? 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 <rlhamil2 at gmail.com>; 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:?+1 (208) 368-4058 ?Fax:?(208)368-2807 Email:?tschmidt at micron.com? 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 <john.horne at plymouth.ac.uk> 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.
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 Aug 5, 2019, at 16:26, Japheth Cleaver <cleaver at terabithia.org> 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: +1 (208) 368-4058 Fax: (208)368-2807 Email: tschmidt at micron.com 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 <rlhamil2 at gmail.com>; 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: +1 (208) 368-4058 Fax: (208)368-2807 Email: tschmidt at micron.com 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 <john.horne at plymouth.ac.uk> 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.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
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 907-465-8591 John.Thurston at alaska.gov 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.
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 <john.thurston at alaska.gov> 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 907-465-8591 John.Thurston at alaska.gov 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.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Guys and gals
The restriction on underscores is:
- for DNS - and may not apply to other naming systems (eg NIS, LDAP, NetBIOS)
- for hostnames - which has a specific meaning in the DNS standards
We shouldn't assume that a name in /etc/hosts or /etc/xymon/hosts.cfg is a hostname in a *DNS* sense. A name that's invalid in a DNS record might still be valid in /etc/hosts or /etc/hostname or wherever. I'm not arguing for a proposal to allow carte blanche, just to not be too restrictive due to our bias towards what we use ourselves (ie, DNS, and mostly DNS hostnames).
A DNS hostname is often associated with an "A" record, but not necessarily. The "hostname" part of a FQDN is *the name of a host*. This seems obvious, but it has (perhaps non-obvious) implications:
It's possible to have DNS domain names that are not hostnames. For example www.example.com is often a *service* name, that may also happen to be the name of a host that runs a webserver, but it might not be a hostname at all. If it's a DNS hostname, then it cannot contain underscores; if it isn't a hostname, then it technically is permitted to contain underscores. When Microsoft developed Active Directory, it intentionally used underscores in *service* names (eg _ldap._tcp.example.com, _sip._ udp.example.com) because they could not legally be used as hostnames, thus ensuring there would be no name collisions with existing hostnames. (Such records are type SRV, in case anyone wants to look it up.)
DNS records that refer to hostnames cannot use underscores in the hostname part. For example, MX (mail exchange) records are required to point to hostnames, and so the right-hand-side of an MX record can not have underscores. The same probably applies to NS records. The same applies to CNAME records that refer to A records on the RHS. CNAMEs aren't always pointing at A records (eg one can have a CNAME point to a TXT record), but when they are, the RHS would not be compliant with an underscore.
That's a bit of a tangent, but it gives a bit more context, to help illustrate where underscores may or may not be used. In essence, there are a few situations where underscores are not permitted in DNS records, but there are plenty of places where they are.
In conclusion, I think we shouldn't be mandating hosts.cfg comply with *DNS* naming standards, and furthermore we shouldn't assume an entry in hosts.cfg is a hostname (vs a service name). However, I believe we should be cautious about what we permit within hosts.cfg (and other sources) to avoid triggering bugs and edge cases.
We should also consider the source if the hostname string. If we receive a string from within hosts.cfg, we should allow the sysadmin to shoot themself in the foot, if they feel they need to, because we can't predict their needs (although we probably want to detect and report obvious typos). On the other hand, if we receive a hostname string from a Xymon client or Xymon proxy, we should be cautious.
Johns's run-around with the CNAME-to-A chain works for an underscore in the CNAME label, at least in BIND DNS. But that doesn't mean it's standards-compliant, nor does it mean it will work with all DNS software. TBH I don't know enough to say that it's not compliant, because it's complicated. BIND will warn about all sorts of semantic problems in a zone, but many of them are accepted-with-warnings, and many others can be accepted by configuration options. RFC2181 specifically says that DNS servers should not refuse to serve a zone based on the make-up of labels in the zone. [https://tools.ietf.org/html/rfc2181#section-11]
In hosts.cfg, we're not necessarily using DNS names, so we should not force the sysadmin to use DNS-compatible names.
Cheers Jeremy
On Tue, 6 Aug 2019 at 08:52, Richard L. Hamilton <rlhamil2 at gmail.com> 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 <john.thurston at alaska.gov> 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 907-465-8591 John.Thurston at alaska.gov 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.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
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://en.wikipedia.org/wiki/Domain_Name_System#Domain_name_syntax,_interna... 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://serverfault.com/questions/963735/syslog-ng-hostnames-with-slashes
And underscore is explicitly mentioned in https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames
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
-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
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.
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
[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.
participants (7)
-
abe@deuxchevaux.org
-
cleaver@terabithia.org
-
jeremy@laidman.org
-
john.horne@plymouth.ac.uk
-
john.thurston@alaska.gov
-
rlhamil2@gmail.com
-
tschmidt@micron.com