On Sun, Mar 21, 2021 at 08:06:46PM -0400, James Ralston wrote:
On Sun, Mar 21, 2021 at 4:24 PM Spike White
> If we limit our KRB5 encryption algorithms to only strong cyphers
> (AES128 and AES256), would that thwart the above SSSD attack?
The fundamental issue is this: if an attacker has compromised a Linux
host, then the attacker has access to any Kerberos credential on that
host, both ticket-granting tickets (TGTs) and service tickets.
This is true regardless of how/where the Kerberos credential is
cached: in a plain file (the FILE: or DIR: cache types), usually in
/tmp; in the kernel keyring (the KEYRING: cache type); or in KCM (the
KCM: cache type).
Obviously, for an attacker, some cache types are easier to extract
than others (e.g., FILE:), but if it’s on the host, the attacker has
it. (If the credential is encrypted, then the key to decrypt it is
also on the host.)
There’s actually another cache method that isn’t well-known: if the
host accesses an NFSv4 server using RPCSEC_GSS (Kerberos)
authentication, the Linux NFSv4 kernel client code will stash the
user’s NFSv4 service ticket for the NFSv4 server in the kernel, in
order to minimize upcalls to userland to acquire the service ticket.
This means that once a user on the NFSv4 client accesses files on the
NFSv4 server, until the cached service ticket in the kernel expires,
anyone with root on the NFSv4 client can access that user’s files on
the NFSv4 server simply by using su/sudo/runas to change to the user’s
uid. This is true even if the user ran kdestroy before logging off,
because kdestroy won’t remove the credential from the Linux NFSv4
kernel client code credential cache. (Other than rebooting the host,
or waiting for it to expire, I know of no way to remove it.)
> Also, our KRB5 tickets expire every 10 hrs.
Ah, but do you enable renewable tickets? Because if you do, if an
attacker acquires the TGT, then until the renewal expiration is
reached, the attacker can simply keep renewing the ticket.
All of this notwithstanding, using Kerberos authentication is still
better than using password authentication, where an attacker who
compromises a host can collect passwords from any users who provide
them (e.g., by using ssh with password or keyboard-interactive
authentication to get onto the host; by running kinit on the
compromised host). And Kerberos credentials tend to expire a lot
quicker than actual passwords do.
I agree with the above, if an attacker can become root on your client
you are lost. I guess it would be similar if you have Administrator
rights on a Window client.
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure