NetBSD Problem Report #8376

Received: (qmail 29823 invoked from network); 11 Sep 1999 17:15:02 -0000
Message-Id: <199909111715.KAA28111@pasillo.wsrcc.com>
Date: Sat, 11 Sep 1999 10:15:01 -0700 (PDT)
From: Wolfgang Rupprecht <wolfgang@wsrcc.com>
Reply-To: wolfgang@wsrcc.com
To: gnats-bugs@gnats.netbsd.org
Subject: suspected kerberos man-in-the-middle bug
X-Send-Pr-Version: 3.95

>Number:         8376
>Category:       security
>Synopsis:       potential kerberos man in the middle attack vulnarability
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    lha
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Sep 11 10:20:01 +0000 1999
>Closed-Date:    Wed Apr 02 16:29:46 +0000 2003
>Last-Modified:  Wed Apr 02 16:29:46 +0000 2003
>Originator:     Wolfgang Rupprecht
>Release:        NetBSD-current
>Organization:
W S Rupprecht Computer Consulting, Fremont CA
>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.
>Release-Note:
>Audit-Trail:

From: joda@pdc.kth.se (Johan Danielsson)
To: wolfgang@wsrcc.com
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: security/8376: suspected kerberos man-in-the-middle bug
Date: 11 Sep 1999 21:22:29 +0200

 Wolfgang Rupprecht <wolfgang@wsrcc.com> writes:

 > >Confidential:   yes

 Someone should fix the gnats mail server. Since I got this, I may as
 well answer.

 > Somebody please tell me that this data is protected by some other
 > cryptographic trick.

 For Kerberos 5, there is a separate checksum of this data. This
 checksum is optional, but at least Heimdal always provides it, and
 always require it, don't know what the MIT code does. And yes, it
 should really be encrypted.

 Kerberos 4 rsh is, unfortunately, broken.

 > recode krb clients to send crytographically protected setup
 > information.

 It's not much you can do about old protocols. The r* commands are all
 broken by design, and should be replaced with something else.

 /Johan

From: Marc Horowitz <marc@mit.edu> (by way of Erik Fair)
To: gnats-bugs@gnats.netbsd.org
Cc:  Subject: Re: security/8376: potential kerberos man in the middle attack
 vulnarability
Date: Fri, 26 Nov 1999 19:00:33 -0800

 Jaromir Dolecek <dolecek@ics.muni.cz> writes:

 >>  Hi,
 >>  this PR is currently marked confidential. I received a reply from 
 >>the submitter
 >>  that he doesn't need it to be confidential or not, just thought it might
 >>  be good idea, because the bug is too dangerous.
 >>
 >>  Before I go and un-confident it, I'd like to know what is our
 >>  policy.  Is it like making critical bugs known to outside world or keeping
 >>  it secret until someone gets to fix it ?

 I looked at this bug report.  There's no secret in there.  I'll be
 closing it soon, anyway, since netbsd doesn't ship the software
 described in the PR.

 		Marc
State-Changed-From-To: open->analyzed 
State-Changed-By: fair 
State-Changed-When: Mon Nov 29 16:32:13 PST 1999 
State-Changed-Why:  
It looks like Marc Horowitz has this one nailed. 
Responsible-Changed-From-To: security-officer->marc 
Responsible-Changed-By: fair 
Responsible-Changed-When: Tue Dec 21 11:28:15 PST 1999 
Responsible-Changed-Why:  
Marc said he'd handle this PR. Any progress to report? 
Responsible-Changed-From-To: marc->security-officer 
Responsible-Changed-By: chs 
Responsible-Changed-When: Thu Sep 20 10:28:11 PDT 2001 
Responsible-Changed-Why:  
it's been almost 2 years, I don't think Marc is going to do anything. 
Marc's mail indicates that netbsd doesn't even ship the code with this 
bug, if that's true then this could just be closed. 
Responsible-Changed-From-To: security-officer->lha 
Responsible-Changed-By: perry 
Responsible-Changed-When: Tue Apr 1 15:39:00 PST 2003 
Responsible-Changed-Why:  
love is helping clear out the kerberos PRs. 

From: "Perry E. Metzger" <perry@piermont.com>
To: lha@netbsd.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: security/8376: suspected kerberos man-in-the-middle bug
Date: 01 Apr 2003 18:38:50 -0500

 The attached text on the PR says that we can close this one.

 Can we close this one?

 (If so, would you close it?)

 Perry
State-Changed-From-To: analyzed->closed 
State-Changed-By: lha 
State-Changed-When: Wed Apr 2 08:16:10 PST 2003 
State-Changed-Why:  
since the rsh commands are broken and current netbsd doesn't support them 
this pr will be closed 
I'll remove all traces of the kerberos support in rsh/rlogin 
(it should be rewritten be used anyway) 

if you want rsh like support, use ssh with krb5 (ssh1) or ssh with gssapi 
>Unformatted:

Home	PR Database Search