lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 09 Jan 2007 14:09:15 -0500
From: Tom Yu <tlyu@....EDU>
Subject: MITKRB5-SA-2006-002: kadmind (via RPC lib) calls uninitialized function pointer

Hash: SHA1

                 MIT krb5 Security Advisory 2006-002

Original release: 2007-01-09
Last update: 2007-01-09

Topic: kadmind (via RPC library) calls uninitialized function pointer

Severity: CRITICAL

CVE: CVE-2006-6143
CERT: VU#481564


The Kerberos administration daemon, "kadmind", can execute arbitrary
code by calling through a function pointer located in freed memory.
This vulnerability results from bugs in the server-side portion of the
RPC library.  Third-party server applications written using the RPC
library provided with MIT krb5 may also be vulnerable.

No exploit code is known to exist at this time.


An unauthenticated user may cause execution of arbitrary code in
kadmind, which can compromise the Kerberos key database and host
security.  (kadmind usually runs as root.)  Unsuccessful exploitation,
or even accidental replication of the required conditions by
non-malicious users, can result in kadmind crashing.

An unauthenticated user may cause execution of arbitrary code in
third-party server applications which use the RPC library.


* kadmind from MIT releases krb5-1.4 through krb5-1.4.4

* kadmind from MIT releases krb5-1.5 through krb5-1.5.1

* third-party applications calling the RPC library included in MIT
  releases krb5-1.4 through krb5-1.4.4

* third-party applications calling the RPC library included in MIT
  releases krb5-1.5 through krb5-1.5.1

* Earlier releases may not be affected because the changes causing
  this vulnerability were introduced in krb5-1.4.


* The upcoming krb5-1.6 release will contain a fix for this problem.
  Additionally, the upcoming krb5-1.5.2 patch release will contain
  this fix.

* Apply the following patch:

Index: src/lib/rpc/svc.c
*** src/lib/rpc/svc.c	(revision 18864)
- --- src/lib/rpc/svc.c	(working copy)
*** 437,442 ****
- --- 437,444 ----
+ extern struct svc_auth_ops svc_auth_gss_ops;
  static void
  svc_do_xprt(SVCXPRT *xprt)
*** 518,523 ****
- --- 520,528 ----
  		if ((stat = SVC_STAT(xprt)) == XPRT_DIED){
+ 		} else if ((xprt->xp_auth != NULL) &&
+ 			   (xprt->xp_auth->svc_ah_ops != &svc_auth_gss_ops)) {
+ 			xprt->xp_auth = NULL;
  	} while (stat == XPRT_MOREREQS);

  This patch is also available at:

  A PGP-signed version of the patch is at:


This announcement is posted at:

This announcement and related security advisories may be found on the
MIT Kerberos security advisory page at:

The main MIT Kerberos web page is at:

CVE: CVE-2006-6143

CERT: VU#481564


Thanks to Andrew Korty from Indiana University for reporting this
problem and for assisting with debugging.


Error handling in svc_do_xprt() calls SVC_DESTROY(), which calls
SVCAUTH_DESTROY(), which calls through a function pointer in a SVCAUTH
structure.  The SVCAUTH structure may reside in uninitialized or freed
memory, so the function pointer may point to malicious or invalid
code, resulting in application crashes or execution of arbitrary
malicious code.

On the server side of the RPC library, each RPC transport socket has a
corresponding SVCXPRT structure.  Every UDP listener has one SVCXPRT,
as does every TCP listener.  UDP listeners do not create a new SVCXPRT
structure for each client; TCP listeners do create a new SVCXPRT
structure for each client.  Each SVCXPRT structure contains a SVCAUTH
pointer named "xp_auth".  The RPC call authentication functions set
subsequently use this SVCAUTH pointer to perform encryption and
decryption of RPC arguments and replies.

During a call, svc_do_xprt() uses the SVCAUTH pointer variable "xprt",
previously set by looking up the transport's socket file descriptor,
to call various functions to perform actual processing of the call.
The AUTH_GSSAPI authentication flavor authentication function,
gssrpc__svcauth_gssapi(), sets xprt->xp_auth to point into an
allocated internal client state structure.  This occurs prior to
authentication actually succeeding; an attacker may not need to
successfully authenticate to exploit this vulnerability.

AUTH_GSSAPI periodically scans all its client state structures for
expired GSS-API contexts, and destroys them.  The client state
structures do not record which xprt->xp_auth points into them; as a
result, the destruction of client state structures can result in some
xprt->xp_auth pointing into freed memory.

When svc_do_xprt() encounters error conditions, it calls
SVC_DESTROY(), which then calls SVCAUTH_DESTROY(xprt->xp_auth) if
xprt->xp_auth is not NULL.  Most of the functions called through
svc_do_xprt() do initialize xprt->xp_auth, but because SVC_RECV() does
not, errors in SVC_RECV() (such as a client closing its TCP socket)
will result in xprt->xp_auth containing whatever value it had at the
conclusion of the immediately preceding call which used that SVCXPRT.

SVCAUTH_DESTROY() calls through a function pointer in xprt->xp_auth.
If xprt->xp_auth points into freed memory, this call could jump to
malicious code.  This vulnerability may be easy to exploit if the
attacker can control the heap contents and writable process memory is

The RPCSEC_GSS authentication flavor currently erroneously depends on
xprt->xp_auth remaining constant across calls, so the simple strategy
of unconditionally setting xprt->xp_auth to NULL will cause
connections using RPCSEC_GSS authentication to fail.  We plan to
address this bug in a future release.


2007-01-09      original release

Copyright (C) 2006 Massachusetts Institute of Technology
Version: GnuPG v1.4.6 (SunOS)


Powered by blists - more mailing lists