>Number:         8376
>Category:       security
>Synopsis:       potential kerberos man in the middle attack vulnarability
>Confidential:   yes
>Severity:       critical
>Priority:       high
>Responsible:    security-officer (NetBSD Security Officer)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Sep 11 10:20:01 1999
>Last-Modified:
>Originator:     Wolfgang Rupprecht
>Organization:
W S Rupprecht Computer Consulting, Fremont CA
>Release:        NetBSD-current
>Environment:
	
System: NetBSD pasillo.wsrcc.com 1.4K NetBSD 1.4K (WSRCC505) #0: Tue Aug 24 19:08:36 PDT 1999 root@capsicum.wsrcc.com:/v/src/netbsd/NetBSD-current/usr/src/sys/arch/i386/compile/WSRCC505 i386


>Description:
	
	If true, (and this still needs to be proven) it looks like
	some core kerberos client code has little to no security
	against man-in-the-middle modification attacks.  I can't
	really believe there really is such a problem -- kerberos has
	been out there close to 20 years, but still I can see the
	vulnarable plaintext fly by on the wire and I can't think o
	what is protecting it.
	
	Someone in the know needs to look at this with the utmost
	urgency.  It true is a very large and exploitable security
	hole.

>How-To-Repeat:
	kinit
	rsh -x remote-machine date
	tcpdump host remote-machine

	Note: it is nessasary to have a hacked tcpdump that prints out 
	packet contents.

        Here is a msg I posted to current-users.
	
	===== 

	I have confirmed that the plaintext command does indeed go across the wire.

	A tcpdump of "rsh -x date" by user "wolfgang".

	    22:48:39.967232 pasillo.wsrcc.com.5120 > capsicum.wsrcc.com.kshell: P 473:494(21) ack 85 win 17520 <nop,nop,timestamp 1238462 1124938>
		    -x date\000wolfgang\000\000\000\000\000 (DF)
	============^^^^^^^^^^^^^^^^^^^

	I'm not sure I really understand this, but on the face of it, it sure
	looks like kerberos's "rsh -x" connections are subject to
	man-in-the-middle modification attacks.  Somebody please tell me 
	that this data is protected by some other cryptographic trick.

	-wolfgang

	From: bam@silas-1.cc.monash.edu.au (Mr Brian May)
	Subject: security of rsh encryption?
	Newsgroups: comp.protocols.kerberos
	Date: 10 Sep 1999 03:41:46 GMT
	Organization: Monash Uni
	Reply-To: bmay@csse.monash.edu.au
	Message-ID: <slrn7tgvfq.he6.bam@silas-1.cc.monash.edu.au>

	Sorry if you receive multiple copies of this message, my ex-newsreader
	was playing up.

	(I hope no one thinks I am being paranoid here, but I have a question 
	concerning the security of the Kerberos rsh protocol with encryption, 
	and I didn't get any response from the heimdal mailing list. I would 
	like to be able to tell others, yes, rsh is secure without hesitation). 

	> From krshd.c in MIT kerberos: 

	    if (status) { 
		if (auth_sys == KRB5_RECVAUTH_V5) { 
		    /* 
		     * clean up before exiting 
		     */ 
		    getstr(netf, locuser, sizeof(locuser), "locuser"); 
		    getstr(netf, cmdbuf, sizeof(cmdbuf), "command"); 
		    getstr(netf, remuser, sizeof(locuser), "remuser"); 
		} 
		return status; 
	    } 

	    getstr(netf, locuser, sizeof(locuser), "locuser"); 
	    getstr(netf, cmdbuf, sizeof(cmdbuf), "command"); 

	[skip a few lines] 

	    getstr(netf, remuser, sizeof(locuser), "remuser"); 


	getstr reads the string in without doing any decryption. ie the 
	values of locuser, command, and remuser are not encrypted. Further 
	on in the code, if I am correct, the read value of cmdbuf is used to 
	enable encryption: 

	    if (!strncmp(cmdbuf, "-x ", 3)) 
		do_encrypt = 1; 

	I have verified that these values are transmitted in plain text by 
	stracing the heimdal implementation of Kerberos. I believe that 
	it uses the same protocol as MIT Kerberos. 

	Now, isn't it highly dangerous to pass the command line in plain text? 
	What if someone where alter the command line after it has been 
	transmitted and turns off encryption?  Even worse, what if they 
	changed the command line to say "rm -rf ."???  Please tell me where I 
	am wrong. 

	(BTW, I have similar concerns for ftp, where a decrypted message may 
	be used when encryption is meant to be enabled, but haven't yet 
	investigated this in as much detail.) 

	Thanks. 

	PS - please send me a CC of all mail, as my news server has been acting 
	very funny lately, and times even losing mail. 

	-- 
	Brian May <bmay@csse.monash.edu.au>


>Fix:
	recode krb clients to send crytographically protected
	setup information.
>Audit-Trail:
>Unformatted: