Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Aug 2017 10:50:33 +0200
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Insecure DNS dependency in many Kerberos deployments

By default, Kerberos clients perform host name canonicalization (search
path resolution, CNAME chain chasing and PTR lookups) to obtain a
service principal name.  This allows service impersonification:

  https://ssimo.org/blog/id_015.html

As a rule of thumb, the impact is similar to running TLS with CA-based
certificate validation, but without host name checks (but perhaps
slightly less because the trust domains could be much smaller).

The Kerberos client library enables this canonicalization by default:

       dns_canonicalize_hostname
              Indicate  whether  name lookups will
              be used  to  canonicalize  hostnames
              for  use in service principal names.
              Setting  this  flag  to  false   can
              improve    security    by   reducing
              reliance  on  DNS,  but  means  that
              short  hostnames will not be canoni‐
              calized  to  fully-qualified   host‐
              names.  The default value is true.

       rdns   If this flag is true,  reverse  name
              lookup  will  be used in addition to
              forward name lookup to  canonicaliz‐
              ing  hostnames  for  use  in service
              principal names.  If  dns_canonical‐
              ize_hostname  is  set to false, this
              flag has  no  effect.   The  default
              value is true.

Some deployments have implemented compatibility with
dns_canonicalize_hostname = false by moving the canonicalization to the
application instead, which is of course equally insecure:

  https://pagure.io/koji/c/fc8a8c6582c5e3b7a8a3a4b887061ba7a3f150a1
  https://bugzilla.redhat.com/show_bug.cgi?id=1481983

Kerberos upstream does not want to enable secure behavior by default
because of backwards compatibility concerns.

Thanks,
Florian

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ