[38347] in Kerberos
Re: security implications of ignore_acceptor_hostname
daemon@ATHENA.MIT.EDU (Ben Gooley)
Fri Sep 28 19:35:37 2018
MIME-Version: 1.0
In-Reply-To: <2bf33b64-80c2-a796-bfbd-8b5201f0f6cf@mit.edu>
From: Ben Gooley <bgooley@cloudera.com>
Date: Fri, 28 Sep 2018 16:35:01 -0700
Message-ID: <CAP9ATs+19GhOkEXjnGNiOBOt7=Qq096=if0c5FCVxBoDrvfcvQ@mail.gmail.com>
To: ghudson@mit.edu
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Thanks for the quick response (on a Friday, no less), Greg.
Since our hadoop servers have their own keytabs and the keys therein have
equal privilege, we should be pretty safe if I read your response
correctly. At least ignore_acceptor_hostname shouldn't introduce much more
risk than without it.
On Fri, Sep 28, 2018 at 4:24 PM Greg Hudson <ghudson@mit.edu> wrote:
> On 09/28/2018 07:13 PM, Ben Gooley wrote:
> > Could someone explain a possible threat due to enabling
> > "ignore_acceptor_hostname=true" with an example? I am trying to assess
> the
> > risk in using that configuration.
>
> If you have keys in the keytab file for multiple hostnames, and the
> application asks for a specific one of them, a client could authenticate
> to the other one instead. An attack might look something like:
>
> * root's keytab has host/machine-hostname and host/service-name,
> service-name being an alias for the web service.
> * www's keytab has host/service-name.
> * sshd asks for an acceptor cred for host@machine-hostname, but the
> library ignores the @machine-hostname part because
> ignore_acceptor_hostname is set to true.
> * An attacker compromises the web service and gains read access to www's
> keytab.
> * The attacker uses the key for host/service-name to print a ticket from
> admin-user to host/service-name.
> * The attacker authenticates to sshd with this ticket and gains root
> access.
>
> The requirements for this attack are (1) a keytab containing keys of
> mixed privilege levels, (2) a compromise of the key for a lower
> privilege level, and (3) a service which is only intended for use with a
> higher privilege level.
>
--
Ben Gooley
*Customer Operations Engineer*
* <http://www.cloudera.com>*
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
