Date: Thu, 5 Nov 1998 14:59:35 -0800 (PST) From: Liam Slusser <liam@tiora.net> To: FreeBSD-security@FreeBSD.ORG Subject: ssh 1.2.26 and kerberos code.. Message-ID: <Pine.BSF.3.96.981105145536.18970B-100000@orbital.tiora.net>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.981105145536.18970B-100000>