COMMAND
	Multiple vulnerabilities in MIT Kerberos 5 releases
SYSTEMS AFFECTED
	MIT Kerberos 5 releases prior to release 1.2.5.
PROBLEM
	In MIT Kerberos security advisory page at:
	
		http://web.mit.edu/kerberos/www/advisories/index.html
	
	--snip--
	* A remote user can crash the KDC.
	* A user authenticated in a remote realm may be able to claim to be
	  other non-local users to an application server.
	* It may be possible for a user to gain access to the KDC system and
	  database.
	--snip--
	
	Problem 1: KDC null pointer dereferences
	________________________________________
	
	Thanks  to  greg  pryzby  <[email protected]>  for  reporting   this
	problem.
	Certain protocol requests, compliant with the protocol  encoding  scheme
	but indicative of a client system most  likely  configured  incorrectly,
	can crash a KDC with a null pointer dereference. We do not  believe  any
	exploit to gain access to the KDC or otherwise  alter  its  behavior  is
	possible on systems without storage mapped at address zero. We have  not
	explored the effects of this on a system with mapped memory  at  address
	zero.
	The fallback and retransmit algorithm used in the MIT krb5 library  will
	cause an application not receiving a reply from a KDC to try other  KDCs
	in the same realm; it will iterate through this list  a  few  times,  or
	until it gets a response. Thus, one client may take down multiple  KDCs.
	We believe this vulnerability is limited to the TGS-REQ  exchange,  that
	is, cases where the user has already authenticated to  the  KDC  or  one
	with which it shares inter-realm keys. So (ignoring cases of  well-known
	passwords) there is an audit trail of sorts, even if it has  to  be  dug
	out of a core file, and it is not a simple,  scriptable  attack  against
	KDCs in general.
	
	Problem 2: realm transit checks
	_______________________________
	
	Thanks to Joseph Sokol-Margolis  <[email protected]>  and  Gerald  Britton
	<[email protected]> for finding this problem.
	Realms with shared  keys  can  impersonate  people  in  other  non-local
	realms in certain cases. It  may  be  exploitable  in  various  ways  if
	non-local principal names are on critical ACLs.
	This  vulnerability  affects  both  the  KDC  and  Kerberos  application
	servers.
	This problem was fixed in the 1.2.3 release. That release also  added  a
	flag to the KDC  config  file  that  can  be  set  to  refuse  untrusted
	cross-realm  authentication,  in  case  application  servers  cannot  be
	updated  quickly  enough.  This  is  not  recommended  as  a   long-term
	solution, because the current model we use  says  that  the  application
	server is responsible for  doing  this  validation,  which  allows  (for
	example) a service on  a  specific  machine  (perhaps  one  set  up  for
	software testing) to be configured to know  about  authentication  paths
	known to the maintainer of the service, even if the  maintainer  of  the
	KDC does not trust  these  paths  for  general  use  within  the  realm.
	Enforcing this limitation in the KDC takes this  option  away  from  the
	maintainers of individual machines.
	
	Problem 3: format strings
	_________________________
	
	Thanks to E. Larry Lidz <[email protected]>  for  discovering
	this problem.
	Older  versions  of  the  MIT  KDC  used  strings  containing   Kerberos
	principal names as printf-style format strings in logging routines.
	At least some cases do not require successful  authentication,  so  this
	can be used as a remote, anonymous attack.
	It is easy to crash the KDC with this exploit. We do  not  know  of  any
	exploits to gain access to the host system, but we do not rule  out  the
	possibility.
	
	Problem 4: bounds checking on data sizes
	________________________________________
	
	Thanks to CERT for bringing this to our attention.
	Some of  our  code  does  not  do  bounds  checking  on  lengths  before
	allocating storage.  On  some  systems,  attempting  to  allocate  large
	negative amounts of storage can crash  the  program.  Thus,  some  bogus
	packets may crash the KDC or an application server  using  Kerberos.  We
	do not believe this can be exploited to gain access to the host system.
SOLUTION
	IT recommends updating to 1.2.7 if possible
	 Workarounds:
	 ============
	 1
	 =
	 - Start your KDC from inittab or a loop in a shell script.  (The
	   inittab approach may not work well if the KDC is crashed too often
	   in a short span of time.)
	 2
	 =
	 - Delete or change inter-realm keys so inter-realm authentication is
	   disabled.
	 - Remove all non-local principals from all critical ACLs in services
	   using old MIT Kerberos code to validate the realm transit path
	 3
	 =
	See under problem 1. ***However, these do not address  the  host  access
	possibility.***
	 4
	 = 
	 - start KDC in a loop in a script, or from inittab
	 - do likewise for any server processes that need to handle multiple
	   client connections