Are Encrypted rlogin Connections (under Kerberos) as Secure as You Think?

David Wagner once observed that his kerberized rlogin session was sending the same packet more than once. This didn't make sense, so he suggested that as a class project, which I did. This web page is an informal discussion of why that occurs in kerberized rlogin with encryption. Comments are welcome, but I probably won't be updating this page frequently. While the Kerberos protocol specifies a packet format that prevents replay attacks (or at least makes them extremely difficult), rlogin doesn't use that format for packets sent once the connection is established. Below, I've included the code for the krb_encrypt packet. Here is the packet format for encrypted protocol messages. For the entire file, see kerberos/kerberosIV/krb/mk_priv.c . 
 * The "out" packet consists of:
 *
 * Size			Variable		Field
 * ----			--------		-----
 *
 * 1 byte		private_msg_ver		protocol version number
 * 1 byte		AUTH_MSG_PRIVATE |	message type plus local
 *			HOST_BYTE_ORDER		byte order in low bit
 *
 * 4 bytes		c_length		length of encrypted data
 *
 * ===================== begin encrypt ================================
 * 
 * 4 bytes		length			length of user data
 * length		in			user data
 * 1 byte		msg_time_5ms		timestamp milliseconds
 * 4 bytes		sender->sin.addr.s_addr	sender's IP address
 *
 * 4 bytes		msg_time_sec or		timestamp seconds with
 *			-msg_time_sec		direction in sign bit
 *
 * 0<=n<=7  bytes	pad to 8 byte multiple	zeroes
 *			(done by pcbc_encrypt())
 *
 * ======================= end encrypt ================================
 */
Below, the function that's used once the connection is established. (In other words, the thing that's used to encrypt your keystrokes and the text sent back to you.) To summarize, it sends the data length to the socket, encrypts the data (right padding if the data is under eight bytes, left padding otherwise),and sends it. The full filed is kerberos/usr.bin/rlogin/des_rw.c 
	/* pcbc_encrypt outputs in 8-byte (64 bit) increments */

	(void) des_pcbc_encrypt((len < 8) ? garbage_buf : buf,
			    des_outbuf,
			    (len < 8) ? 8 : len,
			    key_schedule,	/* DES key */
			    key,		/* IV */
			    ENCRYPT);

	/* tell the other end the real amount, but send an 8-byte padded
	   packet */
	net_len = htonl(len);
	(void) write(fd, &net_len, sizeof(net_len));
	(void) write(fd, des_outbuf, roundup(len,8));
Notice the difference? The second one This format is clearly not as secure as krb_encrypt, and isn't as secure as people think it is.

What about Kerb5

Kerberos version five is a much more complicated system, but even it has the same problem. Kerberos5 separates the encryption from the rest of the program, but they still have the same problem. Below is a bit from krb_encrypt. Notice that it adds a time stamp or sequence number, the sender's IP, and all the rest. 
    if ((krb5_encrypt(bsd_context, (krb5_pointer)buf,
                      desoutbuf.data,
                      len,
                      &eblock,
                      0))){
        fprintf(stderr,"Write encrypt problem.\n");
        return(-1);
    }

    len_buf[0] = (len & 0xff000000) >> 24;
    len_buf[1] = (len & 0xff0000) >> 16;
    len_buf[2] = (len & 0xff00) >> 8;
    len_buf[3] = (len & 0xff);

    if (write(fd, des_outpkt,desoutbuf.length+4) != desoutbuf.length+4){
      fprintf(stderr,"Could not write out all data\n");
        return(-1);
    }
    else return(len);
Notice that like des_write, it writes the length and then send the encryption of the rest. While it is possible that the encryption function takes measures to prevent replay attacks, the mk_priv function clearly does not make that assumption.

Consequences

In essence, this means that the user is vulnerable to a TCP hijacking attack much like the one described by Laurent Joncheray in "A simple active attack against TCP". The attacker does have to work much harder, since the attacker is limited to replaying what packets already sent if the attack is to be other than annoying. Still, it is conceivable that the attacker could hijack the connection, and send packets forming "echo ++ > .rhost" or some other command that could compromise security. In KerberosIV, this problem can even lead to recovery of the session key if the attacker is clever. The paper I presented at presented at NDSS 2000 , for details. Kerberos 5 prevents the possibility of key recovery, but otherwise has many of the same weaknesses. Whether it is an attack anyone would ever actually attempt, I do not know.

Other Relevant Stuff

Below, I've listed the files I mention in the text, and included their full pathnames, so that if you want to untar a Kerberos distribution, you can find them yourself.

KerberosIV files

Kerberos 5 files

Web Pages of Interest

For a complete set of references, view the paper available from NDSS 2000 .
Kris Hildrum
Last modified: Sat Apr 1 14:24:19 PST 2000