Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Nov 1998 21:38:06 -0500 (EST)
From:      Robert Watson <robert@cyrus.watson.org>
To:        Liam Slusser <liam@tiora.net>
Cc:        FreeBSD-security@FreeBSD.ORG
Subject:   Re: ssh 1.2.26 and kerberos code..
Message-ID:  <Pine.BSF.3.96.981105213615.8571B-100000@fledge.watson.org>
In-Reply-To: <Pine.BSF.3.96.981105145536.18970B-100000@orbital.tiora.net>

next in thread | previous in thread | raw e-mail | index | archive | help

I do not know if this applies to the KrbIV code shipped with FreeBSD by
default; the notes below indicate it does apply to the KrbV code.  I
believe Dug Song (sp?) is the maintainer of the KrbIV patch for SSH, and I
believe that the FreeBSD port does not install the patch.  Clearly, this
is of interest if you are running KrbV, however.

On Thu, 5 Nov 1998, Liam Slusser wrote:

> 
> Here is some info ya might like..
>  
> You can find the patch (and the full report from ssh) on rootshell.
> http://rootshell.com/archive-j457nxiqi3gp59dv/199811/sshkerb.txt.html
> 
> liam
> 
> --------------------------------------------------------------------
>  
> This morning SSH Communications Security LTD. released information about a
> buffer overflow in its ssh 1.2.26 client kerberos code.  This came as a
> surprise after SSH was very bullish about there being no buffer
> overflows in their code.  White it is VERY hard to exploit and only works
> under certain conditions, it is still a valid security hole.
>  
> here is the offical statement from ssh.    
>   
>  
>  
> [ http://www.rootshell.com/ ]
>      
> Date:         Thu, 5 Nov 1998 02:38:51 +0200
> From:         Tatu Ylonen <ylo@SSH.FI>
> Organization: SSH Communications Security, Finland  
> Subject:      security patch for ssh-1.2.26 kerberos code  
>  
> -----BEGIN PGP SIGNED MESSAGE-----  
>  
> This message contains information relevant to people who compile ssh
> with --with-kerberos5.  There is one or more potential security
> problem in the Kerberos code.  These issues are not relevant for
> people who have not explicitly specified --with-kerberos5 on the
> configure command line.
>    
> Peter Benie <pjb1008@cam.ac.uk> found a buffer overflow in the
> kerberos authentication code.  To quote from his mail:
>  
> > What about sshconnect.c, line 1139
> >
> >     sprintf(server_name,"host/%s@", remotehost);
> >
> > where remotehost is (char *) get_canonical_hostname() (up to 255 chars),
> > is copied into server_name (a 128 char buffer)? 
>  
> It looks to me like this is a genuine buffer overflow.  I had not
> noticed it when going through the code. 
>  
> This buffer overflow is, however, extremely hard to exploit:
>   1. The victim must have have client compiled with --with-kerberos5 and
>      --enable-kerberos-tgt-passing.
>   2. The victim must be connecting to a server running with the same
>      options (i.e., krb5 with tgt passing).
>   3. You must do the following DNS spoofing:
>        - fake reverse map for the *server*
>        - fake forward map for the fake reversed name
>   4. You must fake your attack code to look like valid DNS records; this
>      is highly untrivial with modern versions of bind that reject all
>      domain names with invalid characters in them.
>   5. Only the part of the DNS name beyond 128 bytes can be exploited; that
>      must be made to align with stack frames and must contain appropriate
>      return addresses and jump addresses.  It has been shown that this can
>      generally be done, but the space and structural constraints here are
>      extremely tight compared to most instances of buffer overflow
>      exploits. 
>   6. Since the client with Kerberos TGT passing is only used 
>      interactively, the user will almost certainly notice that something
>      went wrong.  I don't think you can, within the structure and space
>      constraints, construct the code so that the user would not notice at
>      least the client crashing.
>   7. You cannot try again after a failed attack until the client again
>      tries to log into the same host.
>  
> This might yield an attack against the *client*.  
>  
> I've fixed this in the source tree.
>  
> I'd like to thank Peter for reporting this.  A fix will be included in
> the next release (which I expect in about a week).
> 
> 
> System Administrator Tiora Networks | www.tiora.net <---- tiora's webpage
> www.tiora.net/~liam <----- homepage | liam@tiora.net <-- my email address
> Lowered turbo powered Honda Civic's are really cool. <---------- my quote
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-security" in the body of the message
> 


  Robert N Watson 

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
SafePort Network Services             http://www.safeport.com/
robert@fledge.watson.org              http://www.watson.org/~robert/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.981105213615.8571B-100000>