Thread-topic: MITKRB5-SA-2006-002: kadmind (via RPC lib) calls uninitialized function pointer
> -----Original Message-----
> From: Tom Yu [mailto:tlyu@xxxxxxx]
> Sent: Tuesday, January 09, 2007 10:09 PM
> To: bugtraq@xxxxxxxxxxxxxxxxx
> 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:
>
>
>
> A PGP-signed version of the patch is at:
>
>
>
> REFERENCES
> ==========
>
> 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
>
>
> 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-----
>
