search menu icon-carat-right cmu-wordmark

CERT Coordination Center

KTH Kerberos Telnet implementations do not strictly enforce client encryption request

Vulnerability Note VU#390280

Original Release Date: 2002-02-11 | Last Revised: 2002-04-15

Overview

A vulnerability exists in the KTH Kerberos IV and Kerberos V (Heimdal) Telnet implementations. When a KTH Kerberos Telnet client requests data encryption and the server does not appear to support it, the client will establish the connection using no encryption. A properly located attacker can then capture and read the contents of the Telnet session.

Description

When a user requests an encrypted Kerberos Telnet connection, and encryption cannot be negotiated, the KTH Kerberos IV and Kerberos V (Heimdal) Telnet client implementations proceed to establish the connection using no encryption, transmitting data in clear text. Simon Josefsson has published a paper describing several active man-in-the-middle attacks against the Kerberos Telnet protocol. An underlying vulnerability in the protocol [VU#774587] lets an active man-in-the-middle attacker modify encryption options sent from the server to the client, making it appear that the server does not support encryption. In addition, the attacker can intercept warnings from the server that encryption is not enabled. When a user requests encryption and the server does not appear to support it, the KTH Kerberos Telnet client implementations continue negotiation and establish a connection with no encryption. One defense against this type of attack is for the Kerberos Telnet client to strictly enforce the user's request to encrypt the data stream and terminate the connection if encryption cannot be established.

Impact

An attacker with the ability to modify Kerberos Telnet negotiation commands sent from server to client may be able to cause the connection to negotiate less secure authentication and encryption options, including no encryption. The attacker may then be able to read data that the user presumes to be securely encrypted.

Solution

Enforce Client Encryption Preference

One defense against the attacks described in Josefsson's paper is to strictly enforce the client's preferences and abort the connection if authentication or encryption cannot be negotiated. The following is an excerpt from a man page entry for a BSD-derived telnet command option to enable data encryption:

    -x  Turn on encryption of the data stream.  When this option is turned on,  tel-
        net  will  exit  with  an error if authentication cannot be negotiated or if
        encryption cannot be turned on.

Josefsson references a patch for the KTH Kerberos V (Heimdal) implementation that enforces the client's encryption preference.


Confirm Data Encryption

Confirm that Telnet data is encrypted using a network sniffer.

Vendor Information

390280
 

KTH Kerberos Development Team Affected

Notified:  December 18, 2001 Updated: April 15, 2002

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

As noted in the NEWS file contained in release 1.1.1of the KTH Kerberos 4 implementation (eBones), Telnet has been modified to "abort if telnetd does not support encryption."

If you have feedback, comments, or additional information about this vulnerability, please send us email.

MIT Kerberos Development Team Not Affected

Notified:  December 18, 2001 Updated: February 10, 2002

Status

Not Affected

Vendor Statement

MIT Kerberos Telnet enforces the client's request to use encryption and aborts the connection if authentication or encryption cannot be negotiated.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

BSDi Unknown

Notified:  December 18, 2001 Updated: February 10, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

FreeBSD Unknown

Notified:  December 18, 2001 Updated: February 10, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

NetBSD Unknown

Notified:  December 18, 2001 Updated: February 10, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

OpenBSD Unknown

Notified:  December 18, 2001 Updated: February 10, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.


CVSS Metrics

Group Score Vector
Base
Temporal
Environmental

References

Acknowledgements

The CERT Coordination Center thanks Simon Josefsson for information used in this document.

This document was written by Art Manion.

Other Information

CVE IDs: None
Severity Metric: 5.22
Date Public: 2001-09-12
Date First Published: 2002-02-11
Date Last Updated: 2002-04-15 20:21 UTC
Document Revision: 31

Sponsored by CISA.