Ticket History #5593: kadmind crash on Debian AMD64

See also http://bugs.debian.org/428732

Date: Wed, 13 Jun 2007 15:07:03 -0400
From: Andrew Reid <Andrew.Reid@nist.gov>
To: submit@bugs.debian.org
Subject: Bug#428732: kadmin crashes during password changes

Package: krb5-admin-server
Version: 1.4.4-7etch1

Hi all --

I have a distributed system with a few servers and several
clients, using Kerboros for user authentication and LDAP for
accounts. All servers are Debian "etch", and the clients are
a mix of "etch" and "sarge".

The problem described here may not occur with all clients,
but does occur with at least one client of each of the two
types.

The symptoms are:

A user on a client invokes "kpasswd" or "kpasswd <username>" to
change their password. Kpasswd prompts for their existing
password, accepts the input, then prompts twice for the new password.
It then appears to hang.

Coincident with the hang, kadmind on the server segfaults,
logging the following in /var/log/messages: ("shadrach" is
the server hostname).


The kpasswd process reports a time-out:
.. and the user password is not changed.


The location of the segfault appears to vary, an immediate second
attempt got a slightly different log message:


Issuing /etc/init.d/krb5-admin-server restarts the daemon with
no apparent additional errors.


Behavior is not 100% consistent, I am sure I have seen
instances where a convenience script named "passwd", which just
wraps a call to "exec kpasswd $(whoami)", did not crash the kadmind,
but I am unable to reproduce this desirable behavior just now,
re-running the identical script is crashing the server's kadmind.

I have never seen a direct call to kpasswd fail to crash the
kadmind, but may have always done those second in the testing
sequence.

The bad behavior is correlated with a high frequency of
password changes for a particular principal (one every 60
300 seconds or so). The initial pathology involved a user
whose (new) account was misconfigured, and whose password
was reset within a few minutes of the initial Kerberos principal
creation to facilitate account configuration testing (directly
via kadmin), and then re-reset by the user once the account
configuration was corrected, using kpasswd. This kpasswd operation
crashed the kadmin daemon.

Subsequent experiments on other accounts may have worked
initially, and then begun to fail, consistent with the difficulty
being triggered by multiple password changes within a
few-minute window. Since I have just done this testing, I cannot
immediately test this.

Kernels are stock Debian. Server is 2.6.18-4-amd64,
representative client is 2.6.18-4-k7, libc is 2.3.6.ds1-13
on client and server.

-- A.
--
Dr. Andrew C. E. Reid, Guest Researcher
Center for Theoretical and Computational Materials Science
National Institute of Standards and Technology, Mail Stop 8910
Gaithersburg MD 20899 USA
andrew.reid@nist.gov


Date: Thu, 14 Jun 2007 10:54:18 -0400
From: Andrew Reid <Andrew.Reid@nist.gov>
To: 428732@bugs.debian.org
Subject: Bug#428732: Kadmin crash, additional info

I've had a chance to experiment a little more, and it's
clear that what is crashing the kadmind is a second or
subsequent kpasswd attempt for a given principal a short
time after a (successful) first change.

It's as though there's some time window after a kpasswd
invocation on a principal during which additional kpasswd
invocations will crash the server's admin daemon. It
seems to be independent of the particular principal or
client machine.

-- A.
--
Dr. Andrew C. E. Reid, Guest Researcher
Center for Theoretical and Computational Materials Science
National Institute of Standards and Technology, Mail Stop 8910
Gaithersburg MD 20899 USA
andrew.reid@nist.gov

On Fri, Jul 06, 2007 at 07:53:46PM -0400, Ken Raeburn wrote:

Yes, this describes our situation precisely -- I also had
forgotten about the minimum password lifetime in the policy,
even though I myself remarked on the time-dependent character.

-- A.
--
Dr. Andrew C. E. Reid, Guest Researcher
Center for Theoretical and Computational Materials Science
National Institute of Standards and Technology, Mail Stop 8910
Gaithersburg MD 20899 USA
andrew.reid@nist.gov

On Fri, Jul 06, 2007 at 07:53:46PM -0400, Ken Raeburn wrote:

That's some nice shooting, Ken -- making the suggested change
(adding a <time.h> include) is a fix.

I built a new kadmind binary from the source tree for the -7etch2
version of the Debian package (with helpful instructions, thanks Russ),
and ran it on our server. Now rapid-fire password changes get
a correct response from the server that the minimum password lifetime
has not expired, and the daemon continues to run.

Will there be an "etch" security patch for this for amd64? The daemon
runs as root, so there's a potential exploit opportunity, and even if there
weren't, it's a possible DOS attack.

-- A.
--
Dr. Andrew C. E. Reid, Guest Researcher
Center for Theoretical and Computational Materials Science
National Institute of Standards and Technology, Mail Stop 8910
Gaithersburg MD 20899 USA
andrew.reid@nist.gov