COMMAND

    SSH

SYSTEMS AFFECTED

    SSH-1

PROBLEM

    Following is based o na CORE SDI Security Advisory  CORE-20010207.
    SSH is a widely used client-server application for  authentication
    and  encryption  of   network  communications.    In  1998   Ariel
    Futoransky  and  Emiliano  Kargieman  discovered  a design flaw in
    the SSH1 protocol  (protocol 1.5) that  could lead an  attacker to
    inject malicious packets into  an SSH encrypted stream  that would
    allow execution of arbitrary commands on either client or  server.
    The  problem  was  not  fixable  without breaking the protocol 1.5
    semantics and thus a patch was devised that would detect an attack
    that exploited the vulnerability  found.  The attack  detection is
    done in the file deattack.c from the SSH1 source distribution.

    A vulnerability was found in the attack detection code that  could
    lead to the execution of arbitrary code in SSH servers and clients
    that incorporated the patch.

    This problem affects both SSH servers and clients.  All versions
    of SSH supporting the protocol 1 (1.5) that use the CRC
    compensation attack detector are vulnerable.

    This vulnerability was  found by Michal  Zalewski of the  Bindview
    RAZOR Team.

    Most SSH distributions incorporated the file deattack.c released
    by CORE SDI in 1998.   The file implements an algorithm to  detect
    attempts to exploit the CRC-32 compensation attack by passing  the
    ssh  packets  received  from  the  network  to the detect_attack()
    function in deattack.c

         ...
        /*
           detect_attack
           Detects a crc32 compensation attack on a packet
         */
        int
        detect_attack(unsigned char *buf, word32 len, unsigned char *IV)
        {
            static word16  *h = (word16 *) NULL;
        (*) static word16   n = HASH_MINSIZE / HASH_ENTRYSIZE;
            register word32 i, j;
            word32          l;
         ...

    buf is the ssh packet received, len is the length of that  packet.
    The received packet is  comprised of several blocks  of ciphertext
    of size  SSH_BLOCKSIZE and  each of  them is  checked against  the
    others to  verify that  different packets  dont have  the same CRC
    value, such behavior  is symptom of  an attack.   The detection is
    done using a hash table that is dynamically allocated based on the
    size of the received packet.

        ...
         for (l = n; l < HASH_FACTOR(len / SSH_BLOCKSIZE); l = l << 2);

         if (h == NULL)
         {
           debug("Installing crc compensation attack detector.");
           n = l;
           h = (word16 *) xmalloc(n * sizeof(word16));
         } else
        ...

    Due  to  the  improper  declaration  of  'n' above (it should be a
    word32) by sending  crafted large ssh  packets (length >  2^16) it
    is  possible  to  make  the  vulnerable  code  perform  a  call to
    xmalloc() with an argument of 0, which will return a pointer  into
    the program's address space.

    It  is  worth  mentioning  that  existing  standards  promote  two
    possible  behaviours  for  malloc()  when  it  is  called  with an
    argument of 0:
    - Failure, returning NULL
    - Success,  returning  a  valid  address pointing at a  zero-sized
      object.

    Most modern  systems implement  the later  behaviour and  are thus
    vulnerable.   Systems which  have the  older behaviour  will abort
    the connection due to checks within xmalloc().

    It is then possible to abuse the following code to in order  write
    to  arbitrary  memory  locations  in  the  program  (ssh server or
    client)  address  space,  thus  allowing  an  attacker  to execute
    arbitrary code on  the vulnerable machine,  see lines marked  with
    (*):

          for (c = buf, j = 0; c < (buf + len); c += SSH_BLOCKSIZE, j++)
          {
        (*)  for (i = HASH(c) & (n - 1); h[i] != HASH_UNUSED;
                 i = (i + 1) & (n - 1))
            {
              if (h[i] == HASH_IV)
              {
                if (!CMP(c, IV))
                {
                  if (check_crc(c, buf, len, IV))
                    return (DEATTACK_DETECTED);
                  else
                    break;
                }
              } else if (!CMP(c, buf + h[i] * SSH_BLOCKSIZE))
              {
                if (check_crc(c, buf, len, IV))
                  return (DEATTACK_DETECTED);
                else
                  break;
              }
            }
        (*)   h[i] = j;
          }

    A  would-be  attacker  does  not  need  to authenticate to the SSH
    server first or to have the packets encrypted in a meaningful  way
    to perform the  attack.  Even  if that was  the case, the  session
    key used for  encrypting is choosen  by the ssh  client and it  is
    therefore trivial  to implement  an exploit  (in the  sense of the
    cryptography  knowledge  required  to  do  it).   However, a small
    degree of knowledge  in exploit code  development would be  needed
    to implement a working exploit.

SOLUTION

    OpenSSH versions prior to  2.3.0 are vulnerable.  OpenSSH versions
    2.3.0 and above are  not vulnerable, source changes  in deattack.c
    that fix this  problem were incorporated  into the source  tree on
    October 31st, 2000.

    ssh-1.2.24  up  to  and  including,  ssh-1.2.31  are   vulnerable.
    Versions  prior  to  1.2.24  did  not include the CRC compensation
    attack detector. The official response from SSH.com follows:
    - SSH-2.x is not vulnerable
    - SSH1 is deprecated, and not supported, upgrade to SSH2
    - Nonetheless the proposed patch has been applied to the ssh-1.2.x
      source  tree,  future  releases  of  ssh-1.2.x will have the bug
      closed.

    F-Secure SSH-1.3.x is vulnerable.  Contact the vendor for a fix.

    The default configuration of the AppGate server is not  vulnerable
    since it has SSH-1 support  disabled.  However customers who  need
    ssh1-support can contact support to get patches.

    The MindtTerm client does not have this vulnerability.

    TTSSH is not vulnerable.  All version that incorporated the attack
    detector are not vulnerable.

    LSH does not support SSH protocol 1.

    JavaSSH is not  vulnerable.  The  Java Telnet/SSH Applet  does not
    include CRC attack detection.  A security note regarding Java  SSH
    plugin can be found on:

        http://www.mud.de/se/jta/doc/plugins/SSH.html

    OSSH 1.5.7 and below is vulnerable.  The problem has been fixed in
    version 1.5.8

    Cisco SSH does not appear to be vulnerable.

    The patch included should be  applied to the file deattack.c  from
    the ssh-1.2.31 (and below) source distribution.  Contact your  SSH
    vendor for a  fix if source  code is not  available.  This  is the
    patch for ssh-1.2.31 package.

    --- ssh-1.2.31/deattack.c-old Wed Feb  7 19:45:16 2001
    +++ ssh-1.2.31/deattack.c Wed Feb  7 19:54:11 2001
    @@ -79,7 +79,7 @@
     detect_attack(unsigned char *buf, word32 len, unsigned char *IV)
     {
       static word16  *h = (word16 *) NULL;
    -  static word16   n = HASH_MINSIZE / HASH_ENTRYSIZE;
    +  static word32   n = HASH_MINSIZE / HASH_ENTRYSIZE;
       register word32 i, j;
       word32          l;
       register unsigned char *c;

    For FreeBSD:

        ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-01:24/sshd-4.2-release.patch
        ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-01:24/sshd-4.2-release.patch.asc
        ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-01:24/sshd-4.2-stable.patch
        ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-01:24/sshd-4.2-stable.patch.asc
        ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/security/openssh-2.2.0_2.tgz
        ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/security/openssh-2.2.0_2.tgz
        ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/security/openssh-2.2.0_2.tgz
        ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/security/ssh-1.2.27_3.tgz
        ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/security/ssh-1.2.27_3.tgz
        ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/security/ssh-1.2.27_3.tgz

    For SuSE Linux:

        ftp://ftp.suse.de/pub/suse/i386/update/7.1/sec2/ssh-1.2.27-226.i386.rpm
        ftp://ftp.suse.de/pub/suse/i386/update/7.1/zq1/ssh-1.2.27-226.src.rpm
        ftp://ftp.suse.de/pub/suse/i386/update/7.0/sec1/ssh-1.2.27-220.i386.rpm
        ftp://ftp.suse.de/pub/suse/i386/update/7.0/zq1/ssh-1.2.27-220.src.rpm
        ftp://ftp.suse.de/pub/suse/i386/update/6.4/sec1/ssh-1.2.27-86.i386.rpm
        ftp://ftp.suse.de/pub/suse/i386/update/6.4/zq1/ssh-1.2.27-86.src.rpm
        ftp://ftp.suse.de/pub/suse/i386/update/6.3/sec1/ssh-1.2.27-86.i386.rpm
        ftp://ftp.suse.de/pub/suse/i386/update/6.3/zq1/ssh-1.2.27-86.src.rpm
        ftp://ftp.suse.de/pub/suse/i386/update/6.2/sec1/ssh-1.2.27-210.i386.rpm
        ftp://ftp.suse.de/pub/suse/i386/update/6.2/zq1/ssh-1.2.27-210.src.rpm
        ftp://ftp.suse.de/pub/suse/i386/update/6.1/sec1/ssh-1.2.27-210.i386.rpm
        ftp://ftp.suse.de/pub/suse/i386/update/6.1/zq1/ssh-1.2.27-210.src.rpm
        ftp://ftp.suse.de/pub/suse/sparc/update/7.0/sec1/ssh-1.2.27-221.sparc.rpm
        ftp://ftp.suse.de/pub/suse/sparc/update/7.0/zq1/ssh-1.2.27-221.src.rpm
        ftp://ftp.suse.de/pub/suse/axp/update/7.0/sec1/ssh-1.2.27-221.alpha.rpm
        ftp://ftp.suse.de/pub/suse/axp/update/7.0/zq1/ssh-1.2.27-221.src.rpm
        ftp://ftp.suse.de/pub/suse/axp/update/6.4/sec1/ssh-1.2.27-86.alpha.rpm
        ftp://ftp.suse.de/pub/suse/axp/update/6.4/zq1/ssh-1.2.27-86.src.rpm
        ftp://ftp.suse.de/pub/suse/axp/update/6.3/sec1/ssh-1.2.27-212.alpha.rpm
        ftp://ftp.suse.de/pub/suse/axp/update/6.3/zq1/ssh-1.2.27-212.src.rpm
        ftp://ftp.suse.de/pub/suse/ppc/update/7.0/sec1/ssh-1.2.27-220.ppc.rpm
        ftp://ftp.suse.de/pub/suse/ppc/update/7.0/zq1/ssh-1.2.27-220.src.rpm
        ftp://ftp.suse.de/pub/suse/ppc/update/6.4/sec1/ssh-1.2.27-86.ppc.rpm
        ftp://ftp.suse.de/pub/suse/ppc/update/6.4/zq1/ssh-1.2.27-86.src.rpm