ðòïåëôù 


  áòèé÷ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  óôáôøé 


  ðåòóïîáìøîïå 


  ðòïçòáííù 



ðéûéôå
ðéóøíá














     áòèé÷ :: Security-alerts
Security-Alerts mailing list archive (security-alerts@yandex-team.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[security-alerts] FW: 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:
> 
>   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-----
> 



 




Copyright © Lexa Software, 1996-2009.