Re: [TCLUG:5612] running commands remotely

[Clay Fandre <cfandre@minn.net>]

Luke Francl wrote:

> Make sure you get ssh2 as well. While ssh is more secure than telnet, it
> does have a buffer overflow that can be exploited. This is appearently how
> rootshell.com was cracked. 

> Luke
> 


The only known exploit to ssh1 is when it's compiled with kerberos
support and even then it's very hard to exploit. If you don't need
kerberos support you should be OK. Other than that it has proven to be
very secure.

The biggest problem with ssh2 is that it is only free for non-commercial
use. The commercial licenses are a bit much to justify going to ssh2. We
use ssh1 on all of our servers and workstations here at my Honeywell
division. We turned off telnet (and the r* services) on all of our
server and force users to use ssh/scp. (Windows users can use teraterm
w/ ssh support). It is WAY too easy to sniff passwords these days.

Clay

Below is some info on the buffer-overflow in ssh1.


From a newsgroup post:

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

The patch for this problem is quote simple:
- --- sshconnect.c.orig Thu Nov  5 02:09:55 1998
+++ sshconnect.c        Thu Nov  5 02:10:53 1998
@@ -1090,7 +1090,7 @@
   krb5_data outbuf;
   krb5_error_code r;
   int type;
- -  char server_name[128];
+  char server_name[512];

   remotehost = (char *) get_canonical_hostname();
   memset(&outbuf, 0 , sizeof(outbuf));
@@ -1136,7 +1136,7 @@
        principal and point it to clients realm. This way
        we pass over a TGT of the clients realm. */

- -    sprintf(server_name,"host/%s@", remotehost);
+    sprintf(server_name,"host/%.100s@", remotehost);
     strncat(server_name,client->realm.data,client->realm.length);
     krb5_parse_name(ssh_context,server_name, &server);
     server->type = KRB5_NT_SRV_HST;