Update 20th May 1999: SecureShell 1.2.27 released.
Update 24th November 1999: How to patch SecureShell 1.2.27 Re: ssh-1.2.27 remote buffer overflow - exploitable
Secure shell is a encryption protocol/program for sending and receiving information via possibly insecure networks. This allows you to login to remote machines in a way where the passwords and information are encrypted against possible sniffers/intrusion, that can detect the plain ASCII user names passwords that would normally flow using standard telnet, ftp and other unencrypted protocols.
Bear in mind, some or all of the following could be wrong or non-optimal. Thus this information should not be considered as a substitute for thinking for yourself.
Thanks to Asmodeus for the word to calm down the paranoia (but is still
a good idea to keep everything patched up to date):
"My understanding is as follows: The buffer overrun is in the RSAREF library, which *isn't* compiled in by default. You can see if it is or not by using the verbose mode. (`ssh -v <host>`)" Thus to check out the above:
sv1 101% ssh -v SSH Version 1.2.27 [mips-sgi-irix6.5], protocol version 1.5. Standard version. Does not use RSAREF. Usage: ssh [options] host [command]
To: Exploit-Dev Subject: Re: ssh-1.2.27 remote buffer overflow - exploitable Date: Mon Nov 08 1999 21:24:17 Author: Daniel Jacobowitz Message-ID: [[email protected]] On Tue, Nov 09, 1999 at 01:48:53AM -0000, Frank wrote: > This is submitted to the Freebsd bug tracking system, although there > are doubtless other vendors who leave this package, despite the > existence of the ssh-2.X. While Debian appears to be immune, I was > able to crash my ssh daemon (much to my dismay), and there appears > the potential to execute arbitrary code, as long as you encrypt it > first... > > Here is the freebsd report.. it describes the method to crash a > remote Ssh daemon (lets hope you ran sshd from your xinetd, etc). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=14749 > And here's a patch. Not tested, as I don't use the rsaref glue on any machine here. Dan /--------------------------------\ /--------------------------------\ | Daniel Jacobowitz |__| SCS Class of 2002 | | Debian GNU/Linux Developer __ Carnegie Mellon University | | [email protected] | | [email protected] | \--------------------------------/ \--------------------------------/ --- rsaglue.c.orig Tue Nov 9 11:12:32 1999 +++ rsaglue.c Tue Nov 9 11:17:58 1999 @@ -139,6 +139,10 @@ input_bits = mpz_sizeinbase(input, 2); input_len = (input_bits + 7) / 8; + if(input_bits > MAX_RSA_MODULUS_BITS) + fatal("Attempted to encrypt a block too large (%d bits, %d max) (malicious?).", + input_bits, MAX_RSA_MODULUS_BITS); + gmp_to_rsaref(input_data, input_len, input); rsaref_public_key(&public_key, key); @@ -172,6 +176,10 @@ input_bits = mpz_sizeinbase(input, 2); input_len = (input_bits + 7) / 8; + if(input_bits > MAX_RSA_MODULUS_BITS) + fatal("Received session key too long (%d bits, %d max) (malicious?).", + input_bits, MAX_RSA_MODULUS_BITS); + gmp_to_rsaref(input_data, input_len, input); rsaref_private_key(&private_key, key); |
AllowHosts 127.0.0.1 *.ac.uk DenyHosts ALL:ALL
/usr/local/sbin/sshd
Overall, the idea here is that any unneccessary deamon that runs is a possible entry point for a hacker. Thus only running what you require in a safe manner lessens the chance you system will be compromised and data ruined. The following primarily consists of killing off unneeded deamons in the /etc/inetd.conf. They can always be enabled later on if you find that you do need some of them to run.
Compiling SecureShell on Redhat 6.0 problems.
"There are some pb with the compilation of SSH 2 and Redhat 6.0 To fix your problem: step 1 : execute ./configure step 2: edit the sshconf.h file generated by configure step 3: comment out the line #define HAVE_UTMPX_H 1 step 4: save & run make step 5: make install It worked for me. Good luck"(Lachlan's Note 19th May 1999: This could already be fixed as when I compiled up 1.2.27, I did not have a problem)
From: [email protected] (Greg Bacon)
Newsgroups: comp.security.ssh
Subject: Re: ssh 1.2.27 failing to decrypy keys on make install?
Date: 1 Jun 1999 21:40:38 GMT
Organization: The University of Alabama in Huntsville
References: [[email protected]>
Reply-To: Greg Bacon [[email protected]>
In article [[email protected]>,
[email protected] (Lachlan Cranswick) writes:
: ON an old SGI Indy running IRIX 6.5x, with gcc 2.8.1.
:
: On make install of ssh 1.2.7 - the make just continuous
: generates keys, tests the keys, then gives a
: "private+public failed to decrypt"
Turning down the optimization level has usually solved this problem
for me on IRIX boxen.
Greg
--
Must one first batter their ears, that they may learn to hear with
their eyes? Must one clatter like kettledrums and penitential
preachers? Or do they only believe the stammerer?
-- Nietzsche
From: [email protected] (Andreas Werner)
Newsgroups: comp.sys.sgi.admin
Subject: Re: sshd
Date: 8 Apr 2000 19:42:51 GMT
Organization: Comp.Center (RUS), U of Stuttgart, FRG
there are lots of ways to do this, but the SGI typical way is:
1. Create a file /etc/init.d/sshd containing the following:
====================================
#! /bin/sh
#
# start up ssh server at boot
#
case "$1" in
'start')
if /sbin/chkconfig sshd ; then
if test -x /usr/local/sbin/sshd; then
/usr/local/sbin/sshd
fi
fi
;;
'stop')
/sbin/killall sshd sshd1
;;
*)
echo "usage: $0 {start|stop}"
;;
esac
#
====================================
2. Create two links:
# ln -s ../init.d/sshd /etc/rc0.d/K01sshd
# ln -s ../init.d/sshd /etc/rc2.d/S99sshd
3. Create a config variable:
# chkconfig -f sshd on
That's all, including the possibility to configure the daemon
on or off woth the 'chkconfig' command.
For the experts: Yes, I know that the 'killall' command will
kill user ssh daemons, too, but that's exactly the thing I want
when the machine shuts down ;-)