[Gt-eos] gsissh trusting DNS by default instead of usual rule

[Dave Dykstra]

On Thu, May 16, 2019 at 11:31:56AM +0200, Mischa Salle wrote:
> On Wed, May 15, 2019 at 11:17:01PM +0000, Dave Dykstra wrote:
> > On Tue, May 14, 2019 at 12:41:05PM +0200, Mischa Salle wrote:
> > > On Mon, May 13, 2019 at 03:19:18PM +0000, End of Support of Globus Toolkit wrote:
> > ...
> > > > I recently noticed that gsissh (from gsi-openssh-7.4p1-2.3.osg34.el7)
> > > > does not by default enforce that the expected host name matches the host
> > > > certificate or one of its SANs as is the normal rule for https
> > > > connections.  Instead, it also accepts a DNS alias, unless one sets the
> > > > ssh config option "GSSAPITrustDNS no".  Trusting the DNS by default
> > > > seems to me to be quite a security flaw, and defeats one of the primary
> > > > purposes of X.509 verification.  Could this default be changed?
> > > There seem to be two separate issues here. First of all, according to man
> > > 7 ssh_config:
> > >      GSSAPITrustDns
> > > 	 Set to "yes" to indicate that the DNS is trusted to securely
> > > 	 canonicalize the name of the host being connected to. If "no",
> > > 	 the hostname entered on the command line will be passed
> > > 	 untouched to the GSS- API library.  The default is "no".
> > > so if I understand correctly the current default setting for gsi-openssh
> > > would be to skip hostname verification altogether, so no gridcf-based
> > > library would be involved. I agree I'm puzzled why this is the default
> > > setting?
> > 
> > The man page may say the default is no, but apparently the default is
> > actually yes.  In fact the comment in /etc/gsissh/ssh_config showing
> > the default values says
> > 	#   GSSAPITrustDNS yes
> 
> Ah sorry, I was very confusing there. I quoted from the (standard)
> manpage for openssh since the option itself is not specific for the GSI,
> and I wanted to give the description of the option. I should have
> removed the default (or quote from the gsi-openssh-clients manpage
> (gsissh_config) instead which indeed does state that there the default
> is yes). By the way, that default long-predates the change in the globus
> libraries.

I see, you're right.  It's surprising then that the standard ssh_config
even mentions GSSAPITrustDNS.  If standard ssh supports the GSSAPI
stuff, why do we need gsissh?

> > Actually even when set to "yes" it does verify that the host certificate
> > name (or SAN) matches the DNS alias, so it doesn't completely skip
> > hostname verification.  But it's not worth a whole lot since the DNS
> > isn't secured.
> 
> Just to make clear, you mean it uses something like the old-style (and
> insecure) globus behaviour:
> - user requests host X
> - server resolves X to IP Y
> - server reverse resolves Y to Z
> - server checks Z appears in the hostcert (for Globus that always had to
>   be the CN field, here it seems it could also be SANs)
> while the proper check is to verify that X already appears in the
> hostcert.

I guess that's what it could be doing.  I think though that what it's
actually doing, based on the man page description, is simply looking up
the CNAME in the DNS and passing that to the globus library instead of
the original name.   It says that if the option is "no" it is passed
"untouched", so I think that implies that if the option is "yes", it is
passed "touched" based on the CNAME that the DNS stores to "canonicalize"
the name.

> > > The second point relates to the globus libraries themselves, further
> > > below.
> > > 
> > > > After googling around about this, I found some indication that this
> > > > might be related to a more general issue with the Globus Toolkit, but I
> > > > haven't checked any other tools.
> > > I think this has been changed a few years ago, see also
> > > https://docs.globus.org/security/security-bulletins/2015-12-strict-mode/
> > 
> > Yes I think that's what I was thinking about.  At a rough reading it
> > seems to apply, but as I recall when globus turned this on everybody
> > just had to make sure that the host name was not only listed in the
> > Common Name but was also in the Subject Alternative Name.  I don't think
> > that even the behavior prior to strict mode allowed using DNS aliases
> > the way GSSAPITrustDNS does.
> no, indeed. The old style globus would only verify the CN field, and had
> no support for SANs. I think they changed both at the same time, because
> the reverse DNS lookup was essentially to workaround the problem of
> lacking SAN support as far as I know.

Ok, and GSSAPITrustDNS was probably another workaround for the lack of
SAN support.

The bottom line is that now that globus supports strict mode, gsissh
should change its default for GSSAPITrustDns to "no".

Shall I go ahead and make an issue for it, without including all this
rationale which may attract attention?  Once a new release is available,
however, I think it should be treated as a fixed security vulnerability,
and probably even have a CVE.

Dave