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 <ghud...@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
