SSH Patch Repository

Kerberos buffer overflow

Here is the post to the ssh mailing list on this patch:

From owner-ssh@clinet.fi  Wed Nov  4 19:45:16 1998
Date: Thu, 5 Nov 1998 02:38:51 +0200 (EET)
Message-Id: <199811050038.CAA19536@kuvastin.ssh.fi>
From: Tatu Ylonen 
To: ssh@clinet.fi, kivinen@ssh.fi
CC: Peter Benie , Barry Irwin ,
        cert@cert.org, f-secure-ssh-support@datafellows.com,
        bugtraq@netspace.org
Subject: security patch for ssh-1.2.26 kerberos code
Organization: SSH Communications Security, Finland
Sender: owner-ssh@clinet.fi

-----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).

[patch is below]

However, there are also a few other potential problems in the Kerberos
code.  Special thanks to Barry Irwin  for pointing
out one of them.  I'm not yet sure whether they are exploitable (we
don't have Kerberos installed here, nor documentation for it, so I
can't easily check; however, they might be more serious than the
above).  I'd recommend everyone using ssh with Kerberos authentication
compiled in to install the following full patch, just to make sure.
In addition to the above, it explicitly restricts the length of
various strings.  This also includes the above.

    Tatu

[patch is below]

- -- 
SSH Communications Security           http://www.ssh.fi/
SSH IPSEC Toolkit                     http://www.ipsec.com/
Free Unix SSH                         http://www.ssh.fi/sshprotocols2/

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBNkDyOakZxfGWH0o1AQGYOQP/bUNnE/ZpSQqWVc0ngxLG50+CtyksugLJ
wD0X2yIoc8jmY+UNPL7weQatgv6CmUUoWWpLctzKr8A6G/HrD2sh0OHPBwhIxg1i
3mPj7WrcIX9g/K5LaEksiZ0vv4h/gvSJty5y+wRiu0QLRmuAy91CyaKTV7Sab0YT
/W/s1NazNIg=
=iABB
-----END PGP SIGNATURE-----