[LUGA] Mit freundlicher Unterstützung von:
Linux New Media AG

Mail Thread Index

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MAJOR SSLtelnet security BUG

Habe ich gerade auf der SSL-Liste bekommen. Ich weiß nicht, ob hier jemand 
SSL in einer feindlichen Umgebung verwendet, aber ...

---------- Forwarded message from ssl-lists-owner@minbne.mincom.oz.au on Mon, 1 Apr 1996 18:40:46 +1000 (EST) -----------
Return-Path: <ssl-lists-owner@minbne.mincom.oz.au>
From: Tim Hudson <tjh@mincom.com>
Subject: MAJOR SSLtelnet security BUG
To: ssl-users@mincom.com
Date: Mon, 1 Apr 1996 18:40:46 +1000 (EST)
Reply-To: tjh@mincom.com
X-Mailer: ELM [version 2.4 PL24 ME4]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1949
Sender: ssl-lists-owner@mincom.oz.au
Precedence: bulk

There is a *MAJOR* security bug in the ssl interface code in SSLtelnet 
(nothing to do with SSLeay ... just bad coding in one specific area
in the ssl interface code to the telnetd authenticiation routines).

All versions of SSLtelnet after SSLtelnet-0.2 and prior to SSLtelnet-0.8 
and versions of SSL-MZtelnet prior to SSL-MZtelnet-0.5.2c are effected. 

Updated versions are available from

Older versions of SSLtelnet have been removed from the archive site.

If you have compiled with SSL support (-DUSE_SSL) and are running without
-z certsok as the args to telnetd then you are vulnerable to non-password
checked logins from a *modified* SSLtelnet client.

Thanks to Christoph Martin for noticing this problem and tracking it down.

This is yet another example of the sanity of having source publically 
available for review!

If you are running one of these then switch on -z certsok for telnetd
and you will not be effected by this coding bug.

Tim Hudson


Edit lib/libtelnet/ssl.c

Remove the lines marked with XXXX at the end of auth_ssl_status

int auth_ssl_status(ap, name, level)
        } else {
            /* we force the user to provide a password (over the
             * encrypted channel to do "normal" authentication
XXXX        if (UserNameRequested && auth_ssl_valid) {
XXXX                strcpy(name, UserNameRequested);
XXXX                return(AUTH_VALID);
XXXX        } else

i.e. you need to end up with the following:

        } else {
            /* we force the user to provide a password (over the
             * encrypted channel to do "normal" authentication


   _  | Peter J. Holzer             | Contrary to popular belief, Unix is very 
|_|_) | Sysadmin WSR                | user friendly. It just happens to be very
| |   | hjp@wsr.ac.at               | selective about who it's friends are.
__/   | http://wsrx.wsr.ac.at/~hjp/ |     -- Kyle Hearn

powered by LINUX the choice of a gnu generation
linux user group austria;
Letzte Änderung:
September 2010