Message-ID: <ldvmz4sggpw.fsf@cathode-dark-space.mit.edu>
Date: Tue, 09 Jan 2007 14:09:15 -0500
From: Tom Yu <tlyu@....EDU>
To: bugtraq@...urityfocus.com
Subject: MITKRB5-SA-2006-002: kadmind (via RPC lib) calls uninitialized function pointer

-----BEGIN PGP SIGNED MESSAGE-----
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

SUMMARY
=======

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.

IMPACT
======

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.

AFFECTED SOFTWARE
=================

* 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.

FIXES
=====

* 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 ----
  #endif
  }
  
+ 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){
  			SVC_DESTROY(xprt);
  			break;
+ 		} 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:

  http://web.mit.edu/kerberos/advisories/2006-002-patch.txt

  A PGP-signed version of the patch is at:

  http://web.mit.edu/kerberos/advisories/2006-002-patch.txt.asc

REFERENCES
==========

This announcement is posted at:

 http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2006-002-rpc.txt

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

        http://web.mit.edu/kerberos/advisories/index.html

The main MIT Kerberos web page is at:

        http://web.mit.edu/kerberos/index.html

CVE: CVE-2006-6143
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6143

CERT: VU#481564
http://www.kb.cert.org/vuls/id/481564

ACKNOWLEDGMENTS
===============

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

DETAILS
=======

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
this SVCAUTH pointer, and SVCAUTH_WRAP() and SVCAUTH_UNWRAP()
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
executable.

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.

REVISION HISTORY
================

2007-01-09      original release

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

iQCVAwUBRaL90KbDgE/zdoE9AQKSPwP/TfCAdMA3WQmch7TJQqU8IZF4TyLe6N8N
HJLLKOrEV/ZRyX8nZ+VJuK4FHYEZ02A2hlh3KG3+JQEuB2ChrCxhZz+3sttZJ7rE
/kTmjFwP0BNwIolQ4wYHaVUSGhqK71fJxWt9LIP1Xt/D2dpF0JzmpsvARsfn7yE1
YRQyFUGwRkc=
=2Oi2
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists