From owner-freebsd-security Thu Nov 5 18:38:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA05451 for freebsd-security-outgoing; Thu, 5 Nov 1998 18:38:38 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA05444 for ; Thu, 5 Nov 1998 18:38:34 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id VAA08649; Thu, 5 Nov 1998 21:38:06 -0500 (EST) Date: Thu, 5 Nov 1998 21:38:06 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Liam Slusser cc: FreeBSD-security@FreeBSD.ORG Subject: Re: ssh 1.2.26 and kerberos code.. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 > 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 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