[CCP14 Home: (Frames | No Frames)]
CCP14 Mirrors: [UK] | [CA] | [US] | [AU]

(This Webpage Page in No Frames Mode)

CCP14

Methods, Problems and Solutions

Linux Information for Crystallography

Obsolescent Tutorial on Compiling Secure Shell 1.2.27 for Linux/UNIX

(including insertion of Nov 1999 patch for ssh 1.2.27 to solve buffer overflow exploit)

then Disabling Unrequired Deamons such as telnetd, ftpd, fingerd, rshd, rlogind, etc

The CCP14 Homepage is at http://www.ccp14.ac.uk

[To Problems and Solutions]
[To: BSD UNIX Information for Crystallography]
[To: Linux Information for Crystallography]
[Back to Installing a Linux and Win95 Dual Boot System] | [Back to Compiling Secure Shell for Linux/UNIX]

Obsolete: check out Compiling and Installing OpenSSH (Secure Shell clone) for Linux/UNIX

Overview

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.

Download and Install Secure Shell

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: [19991109112417.A30046@drow.res.cmu.edu]


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   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

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


Enhancing the Security of the system by disabling unneccessary deamons

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)


Problem with compiling up ssh 1.2.27 on an old Indy running IRIX 6.5.x

From: gbacon@itsc.uah.edu (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: [l.cranswick.299.002A3BCE@dl.ac.uk>
Reply-To: Greg Bacon [gbacon@cs.uah.edu>

In article [l.cranswick.299.002A3BCE@dl.ac.uk>,
        l.cranswick@dl.ac.uk (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


Getting ssh to run on startup on an SGI running IRIX

From: werner@visaw.rus.uni-stuttgart.de (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 ;-)


[To Problems and Solutions]
[To: BSD UNIX Information for Crystallography]
[To: Linux Information for Crystallography]
[Back to Installing a Linux and Win95 Dual Boot System] | [Back to Compiling Secure Shell for Linux/UNIX]

[CCP14 Home: (Frames | No Frames)]
CCP14 Mirrors: [UK] | [CA] | [US] | [AU]

(This Webpage Page in No Frames Mode)

If you have any queries or comments, please feel free to contact the CCP14