Bug 2969 - Too relaxed rules on DN comparisons (all versions of GT)
: Too relaxed rules on DN comparisons (all versions of GT)
: unspecified
: All All
: P3 major
: ---
Assigned To:
  Show dependency treegraph
Reported: 2005-03-17 06:21 by
Modified: 2008-09-23 15:32 (History)



You need to log in before you can comment on or make changes to this bug.

Description From 2005-03-17 06:21:28
See mail from the UK e-Science CA below. Looking at the source code
(gssapi/source/library/compare_name.c), it was very easy to spot the problem:
it's well documented, and it has been there for ages:

     * Many site use the convention of naming interfaces
     * by having the FQDN in the form host-interface.domain
     * and the client may only know the host-interface.domain
     * name, yet it may receive a target of host.domain
     * So we need host.domain to compare equal to
     * host-interface.domain

This exception is lethal when you name the front-end node of a cluster foo.com
and the worker nodes foo-001.com, foo-002.com, ...

I'm not sure this feature should be completely removed. But I would suggest it
to be disabled by default, and that a fix is made available immediately.


On Mar 17, 2005, at 18:35, Jensen, J (Jens) wrote:

Hi Olle,

With your Globus experience, I thought I'd bounce this one off you.
Even if you don't know the answer you probably know who knows...

Apparently Globus interprets hyphens in DNS names as a sort of
wildcard in the following sense: suppose I issue a host certificate to
lcgce.gridpp.rl.ac.uk.  Then, on a host with DNS name
lcgce-*.gridpp.rl.ac.uk, that certificate will be accepted as a valid

For example, a CE admin can name the WNs lcgce-001.gridpp.rl.ac.uk to
lcgce-099.gridpp.rl.ac.uk, and install the certificate/key for
lcgce.gridpp.rl.ac.uk on all the machines, and they would be accepted
as valid host certificates by Globus.  Of course the CA wouldn't allow
this because private keys MUST NOT be shared.

Now, as you know, RFC2595, section 2.4 ("Server identity check"),
explicitly defines a wildcard mechanism allowing wildcards.  We can
also place multiple names in the subjectAltName.  (Of course the RFC
also requires that all the names are bound to a single host.)

Using wildcards and multiple subjectAltName entries is defined by the
CA, however, in the CP/CPS.  The hyphen mechanism is an extra added
additional Globus "feature", and the CA has no control over this.

It also weakens the security mechanism; for example, suppose Alice
administrates grid-data.rl.ac.uk and is blissfully unaware of the
hyphen mechanism.  Bob, our rogue admin, can set up new hostnames in
DNS and sets up grid.rl.ac.uk and gets a host certificate for this
machine.  Then he changes the DNS record for grid-data to point to
grid.rl.ac.uk.  Globus clients will happily accept this change.
Had Bob asked for a certificate for grid-data, the CA would at least
have denied this (knowing that Alice already had that).

To counteract this, the CA must apparently restrict the use of hyphens
in (leftmost) DNS names, *or* at least keep track of which admins own
which names and have host certificates for them.  Perhaps it's not a
devastating attack but it does weaken the guarantee that the CA gives,
namely that hostnames are tied to a specific host and the ownership of
the host certificate is well defined.

So, I thought I'd check with you if you know whether that "feature" is
going to be a permanent addition to Globus, and indeed why we have it
at all rather than just using wildcards.  Are there other such features
we should know about?

Many thanks,
------- Comment #1 From 2005-04-07 12:32:59 -------
Updated Java code with the fix. Sam has fixed the C code.

------- Comment #2 From 2005-04-07 12:38:44 -------
What is the fix?

There are probably many users using the dash trick, so you have to be very clear
on how upgrading to GT4 will affect them.
------- Comment #3 From 2005-04-07 12:51:43 -------
The fix was to no longer allow host-interface.domain to compare successfully
with host.domain. This will break the setup for those people who used this feature.

------- Comment #4 From 2005-04-07 13:09:55 -------
Where is this change documented?  Are we *guaranteeed* that people upgrading
from previous 
versions will find out about it?  Is it in release notes?  Have we documented
what people who depended 
on this should do now that we've "fixed" the feature?  Has anyone consulted our
project liasons to find 
out whether this is going to adversely affect anyone or not?

We should not be making changes that affect features that people have depended
on in the past 
without taking extraordinary measures to communicate that we've made the
change.  I see nothing in 
the comments closing out this bug that such measures have been taken.  Either:

1) Document the communication that is happening here before closing out the
bug, or
2) Figure out what communication needs to be done and do that work before
closing out the bug.
------- Comment #5 From 2005-04-07 17:32:10 -------
> Where is this change documented?

As far as I know, the feature was never documented in the first place (and
I've never used it for that reason).

This doesn't refute Lee's point; some users are depending on the feature,
and they'll need to be informed.
------- Comment #6 From 2005-04-07 17:59:38 -------
I would be willing to bet that Keith is right--it wasn't documented, aside from
in the code that Olle 
found.  These are the worst kinds of situations!  I'm quite sure that this
feature was added prior to 
2000, because I think it was there when I started at Argonne in 1999-Dec.  I am
pretty sure that NASA 
was using it then, and may still be. But it was never documented, so we don't
really know whether it's a 
bug or a feature, and thus we don't know whether it's safe to remove it / fix
it or not.  I personally think 
that we should err on the side of caution, because the feature was put there to
support some of the 
large infrastructure deployment projects and changing things now without
investigating what this will 
break could result in some really big downsides.  (Like a big deployment
refusing to move to GT4 until 
we "fix" the "fix.")  But I'm willing to be overruled.
------- Comment #7 From 2005-04-08 09:32:47 -------
This feature was added by Doug Engert way back, probably prior to GT2. Whether
it was in response to a user request or just of his own invention, I don't know.

Olle has notified the major US and EU PMAs which should reach much of the target

I believe we need to either remove this or fully support it. I personally vote
for removal, as it's prone to problems.

Below is a blurb I sent to the board regarding this which could be forward to
project leads for further disssemination.

In GT4 we are planning on removing a feature/bug in GT that allowed host names
with dashes to be equivalent to the same hostname without a dash
(e.g. "somehost-eth1.ncsa.uiuc.edu" would equate to
"somehost.ncsa.uiuc.edu"). This feature, which dates back to GT2
at least, was never documented and there have been concerns raised recently
regarding it causing potential security vulnerabilities. Given a choice between
fully documenting and supporting this feature or removing it, we believe the
right choice is to remove it.
------- Comment #8 From 2005-04-08 09:45:57 -------
Note that my comment was not whether to remove the feature or not, but making
sure it is made clear to users who is upgrading from a previous version. I
suggest to mention it in the migration guides:


as well as in the security chapter of the admin guide:

------- Comment #9 From 2005-04-08 11:30:53 -------
This might merit a new Bugzilla entry, but my recommendation would be to update
the documents that 
Mats pointed to (security section of admin guide and the two migration guides),
but rather than just 
"mention the change", actually explain how to handle the host certs and
services for a multi-homed 
system now that you can't use a single host cert.  I don't see anything in
there already on how to deal 
with that scenario, and it seems that we have people in that situation.

Should that be a new Bugzilla entry?
------- Comment #10 From 2005-04-12 08:34:00 -------
Backed out the change for now.

------- Comment #11 From 2005-06-29 15:59:43 -------
Was this applied to globus_4_0_branch again?

From a Java client:

org.globus.common.ChainedIOException: Authentication failed [Caused by:
Operation unauthorized (Mechanism level: Authorization failed. Expected
"/CN=host/viz-1.isi.edu" target but received
        at org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
        at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:144)

From a C client:

globus_xio_gsi: gss_init_sec_context failed.
GSS Major Status: Unexpected Gatekeeper or Service Name
globus_gsi_gssapi: Authorization denied: The name of the remote host
(viz-login.isi.edu), and the expected name for the remote host (viz-1.isi.edu)
do not match. This happens when the name in the host certificate does not match
the information obtained from DNS and is often a DNS configuration problem.

------- Comment #12 From 2005-08-02 17:11:08 -------

No the code is still in the C code at least. The problem is that it is doesn't
work the way you expect.

From reading the code, the way it works is essentially "hostname" is equivalent
to "hostname-foo", but "hostname-bar" is not equal to "hostname-foo". E.g.:

foo.ncsa.uiuc.edu == foo-bar.ncsa.uiuc.edu
foo-1.ncsa.uiuc.edu == foo.ncsa.uiuc.edu


foo-1.ncsa.uiuc.edu != foo-bar.ncsa.uiuc.edu

In other words a "-extension" is removed from one hostname or the other before
comparison, but not both.

I am leaving this bug as open as we really need to document this behavior.
------- Comment #13 From 2005-08-02 18:25:24 -------
That explains why it doesn't work, but does not explain why it used to. I have
been running older version of Globus which used to work on the same machine.

I'm not affected by this bug anymore as we have switched to having a hostcert
for each node (there are only 9). I agree that the behavior should be well
------- Comment #14 From 2005-08-02 22:34:20 -------
I cannot find any change in the code back to 1.1 in CVS that would explain
You had the dash in the first part of the hostname right? The only change that
looks like it could be relevant is the following:

revision 1.13
date: 2002/11/01 14:07:10;  author: meder;  state: Exp;  lines: +11 -4
branches:  1.13.2;  1.13.4;  1.13.6;

fix bug in compare name: pitcairn.mcs-foo.anl.gov would compare
favorably with pitcairn.mcs.anl.gov.
------- Comment #15 From 2005-08-03 09:58:57 -------

The current Java code does not match host1-foo and host1-bar, but will match 
host1 and host1-foo. Nothing in commit logs suggest the first case was allowed 
before. Is there a specific version where it worked ? I could try and see if 
there is a branch/tag in jglobus code that allows for it. also, I will add 
notes to the document about this.

------- Comment #16 From 2005-08-03 11:20:30 -------
Hmm, maybe I'm wrong. I do not have the old hostcert anymore, so I can not
verify what the subject really was. I thought it was viz-login.isi.edu and that
worked on viz-{n}.isi.edu, but now I'm not sure anymore.
------- Comment #17 From 2005-10-11 10:23:24 -------
Discussed with Mats and he hasn't seen any issues since. Closig bug.
------- Comment #18 From 2005-10-11 20:53:34 -------
A solution to disable the feature by default, but retain it seems like middle 
ground. I am not sure of the implications of this for communities that are 
using it and would appreciate people weighing in on that. If we agree we need 
to make this change, then we can put out a security advisory and update package 
for it.
------- Comment #19 From 2005-10-11 21:28:09 -------
I think changing default behavior at this point would be a mistake.

I suggest we document current behavior and inform those that feel strongly that
we would be willing to accept a patch allowing the behavior to be disabled.
------- Comment #20 From 2005-10-11 21:54:27 -------
Current behavior has been documented in "Security considerations" section of 
Pre-ws AA and WS AA. Here is how it looks now:

------- Comment #21 From 2005-10-12 08:49:09 -------
If we don't want to change default behavior, do we want to allow for a 
configuration to disallow this ? This might make it easier for installations 
where they want this feature disallowed.
------- Comment #22 From 2005-10-12 09:05:48 -------
I would suggest that if someone wants to be able to disable this behavior, we
should welcome a contribution that allows for such a configuration change.
------- Comment #23 From 2008-09-23 15:32:51 -------
As part of this campaign
(http://bugzilla.globus.org/globus/show_bug.cgi?id=6331) I added support for
subjectAltName with DNS and/or IP address matching (for GSI C).

There's also an environment variable for disabling this and other non-standard
behaviors (see http://bugzilla.globus.org/globus/show_bug.cgi?id=6331#c1). I'll
update the doc for 4.2.1 where this code will first be public.