OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: BindView Security Advisory (advisory+ssh1crcBOS.BINDVIEW.COM)
Date: Thu Feb 08 2001 - 17:03:14 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

     Remote vulnerability in SSH daemon crc32 compensation attack detector
    -----------------------------------------------------------------------

    Issue date: 8 February 2001

    Author: Michal Zalewski <lcamtufrazor.bindview.com>
    Contact: Scott Blake <blakerazor.bindview.com>

    CVE: CAN-2001-0144

    Topic:

    Remotely exploitable vulnerability condition exists in most ssh daemon
    installations (F-SECURE, OpenSSH, SSH from ssh.com, OSSH).

    Tested against:

      ** Vulnerable:

         SSH 1.2.x (ssh.com) -- all recent releases

         F-SECURE SSH 1.3.x -- all recent releases

         OpenSSH prior to 2.3.0 (unless SSH protocol 1 support is disabled)

         OSSH 1.5.7 (by Bjoern Groenvall) and other ssh1/OpenSSH derived
         daemons

      ** Not vulnerable:

         SSH2 (ssh.com): all 2.x releases
         NOTE: SSH2 installations with SSH1 fallback support are vulnerable

         OpenSSH 2.3.0 (problem fixed)

         SSH1 releases prior to 1.2.24 (vulnerable to crc attacks)

         Cisco SSH (own implementation)

         LSH (SSH protocol 1 not supported)

      ** Other SSH daemons: not tested

    Overview:

    An integer-overflow problem is present in common code of recent ssh daemons,
    deattack.c, which was developed by CORE SDI to protect against cryptographic
    attacks on SSH protocol.

    Impact:

    Insufficient range control calculations (16-bit unsigned variable is
    used instead of 32-bit, which causes integer overflow) in the
    detect_attack() function leads to table index overflow bug.

    This effectively allows an attacker to overwrite arbitrary portions of
    memory. The altered memory locations affect code that is executed by
    the daemon with uid 0, and this can be leveraged to obtain general
    root access to the system.

    Details:

    When the condition described above occurs, a 32-bit local variable,
    which is set to 65536 for large input buffers, is assigned to a 16-bit
    local variable, effectively causing it to be set to 0. Due to specific
    malloc(0) behavior, memory allocation routine will be passed, creating
    buffer of size (malloc_usable_size) 12. Next:

                  for (i = HASH(c) & (n - 1); h[i] != HASH_UNUSED;

    We can see n-1 here, and n is equal to 0. Because i is an unsigned
    32-bit integer, it would cause integer overflow. This code will be
    equal to i = HASH(c) & 0xffffffff. Binary AND operator reduces this
    to i = HASH(c). Pointer 'c' is referencing client-provided cryptographic
    packet, and HASH function is simply responsible for changing byte
    order in input stream.

    Then, detect_attack() routine is trying to access h[i], causing
    segmentation fault due to table index overflow bug.

    To reproduce this condition, run your sshd server on localhost under gdb
    with '-d' switch (to avoid forking). Then try (using OpenSSH client -
    ssh.com client software crops the login name):

    $ ssh -v -l `perl -e '{print "A"x88000}'` localhost

    Program received signal SIGSEGV, Segmentation fault.
    0x806cfbd in detect_attack ( ..., len=88016, IV=0x0) at deattack.c:138
    136 for (i = HASH(c) & (n - 1); h[i] != HASH_UNUSED;

    We can inspect the table index (SEGV happened during h[i] !=
    HASH_UNSIGNED comparsion):

    (gdb) printf "%x\n",i

    Results may vary with every connection, depending on the entropy seed
    used by the client, crypto keys, etc. You can easily produce a wide
    32-bit range of indexes by changing client parameters or simply
    reconnecting. It is obvious there wouldn't be a problem to specify very
    large index that would point outside our table, but will cause address
    space wrap to point accessible memory (stack or another segment). Then,
    few lines below, in the same loop, we can find following statement:

                  h[i] = j;

    ...where j is a simple block counter.

    Conclusion:

    By carefully preparing encrypted data, an attacker can point used,
    accessible memory (that would pass check in line 136 without SEGV), and
    then, he will able to alter dword at chosen address, replacing it with
    value of j. The attacker can alter stack variables, alter malloc
    structures, etc, and attack later due to improper execution of daemon
    code. This condition is relatively difficult to exploit, but there are
    no technical reasons that would make this impossible.

    Currently, we are not aware of working exploits for this vulnerability.

    Note that the attacker needs to make a TCP connection from an IP
    address for which sshd will enter into a key-exchange dialogue. If the
    attacker's packets have a source IP address that is disallowed by
    (for example) DenyHosts in the sshd configuration file, the key
    exchange will not happen and the attacker will not have an opportunity
    to compose the required exploit data.

    Solution:

    Included are a few patches for various versions/implementations of SSH.
    This is not meant to be an all-inclusive list, as there are a number of
    implementers of SSH daemons that are not open source. If you *do* have
    the source code for SSH, it should be fairly simply to study the patches
    below, see what has been done, and patch your own code. Note that this
    is a fix for the one issue that we've found, and should not be construed
    as the results of a complete audit of the code.

    SSH1 software:

    8<---------------------patch for ssh-1.2.31---------------------------
    --- deattack.c.orig Wed Feb 7 13:53:47 2001
    +++ deattack.c Wed Feb 7 13:54:24 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;
    8<---------------------patch for ssh-1.2.31---------------------------

    Bjoern Groenvall's ossh (ftp://ftp.pdc.kth.se/pub/krypto/ossh/):

    8<---------------------patch for ossh-1.5.7---------------------------
    --- deattack.c.orig Wed Feb 7 14:11:23 2001
    +++ deattack.c Wed Feb 7 14:11:46 2001
    -91,7 +91,7
     detect_attack(const unsigned char *buf, word32 len)
     {
       static u_int16_t *h = (u_int16_t *) NULL;
    - static u_int16_t n = HASH_MINSIZE / HASH_ENTRYSIZE;
    + static u_int32_t n = HASH_MINSIZE / HASH_ENTRYSIZE;
       register word32 i, j;
       word32 l;
       const unsigned char *c, *d;
    8<---------------------patch for ossh-1.5.7---------------------------

    OpenSSH:
    Upgrade to 2.3.0 or above. If you have 2.2.0:

    8<-------------------patch for openssh-2.2.0--------------------------
    --- deattack.c.orig Wed Feb 7 14:18:23 2001
    +++ deattack.c Wed Feb 7 14:19:33 2001
    -84,7 +84,7
     detect_attack(unsigned char *buf, u_int32_t len, unsigned char *IV)
     {
            static u_int16_t *h = (u_int16_t *) NULL;
    - static u_int16_t n = HASH_MINSIZE / HASH_ENTRYSIZE;
    + static u_int32_t n = HASH_MINSIZE / HASH_ENTRYSIZE;
            register u_int32_t i, j;
            u_int32_t l;
            register unsigned char *c;
    8<-------------------patch for openssh-2.2.0--------------------------

    Vendor Response:

    CORE SDI has issued their own advisory detailing fix information and
    has also pointed out that SSH1 clients are also vulnerable.

    Bjorn Gronvall - OSSH
      Fixed in version ossh-1.5.8

    AppGate
      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
      supportappgate.com to get patches.

    Mindbright
      The MindTerm client does not have this vulnerability.

    SSH
      Current release 2.4.0 is not vulnerable. Previous versions
      of SSH1 are not supported but a fix has been commited to the
      source tree. SSH recommends customers upgrade to SSH2.

    F-Secure
      Unfortunately, after many attempts to contact F-Secure via
      email and telephone no response has been received.

    Thanks:

      Special thanks to Mark Loveless for his significant contributions to the
      Fix section. Thanks to RAZOR team members Todd Sabin, Scott Blake, and
      Steve Manzuik for their assistance with this issue. Thanks also to Ivan
      Arce of CORE SDI for his patience with us.

    _____________________________________________________________________
    ** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice"
    ** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST"
    SEND ALL COMMANDS TO: listservlistserv.ntsecurity.net