OpenSSH remote root compromise all version
Results 1 to 8 of 8

Thread: OpenSSH remote root compromise all version

  1. #1
    Senior Member
    Join Date
    Apr 2002
    Posts
    1,049

    OpenSSH remote root compromise all version

    well this is for all you *nix admins that run OpenSSH taken from www.xatrix.org

    http://www.xatrix.org/article2499.html

    After more than six months of intensive underground research, our ISO 31337 certified security department evidenced that the bug (an integer overflow, resulting in a heap overflow) described in the aforementioned advisory still exists in OpenSSH 3.5p1 and 3.4p1, and remains trivially exploitable.


    The following advisory is based on the excellent advisory published by
    Global InterSec LLC *six months ago*:

    http://www.globalintersec.com/adv/op...2002062801.txt

    After more than six months of intensive underground research, our ISO
    31337 certified security department evidenced that the bug (an integer
    overflow, resulting in a heap overflow) described in the aforementioned
    advisory still exists in OpenSSH 3.5p1 and 3.4p1, and remains trivially
    exploitable. All existing PAM enabled versions of OpenSSH (3.5p1, 3.4p1
    and below) are therefore affected.

    Due to various advisories posted to various fora by unnamed security
    companies, this bug was supposed to be nonexistent or nonexploitable.
    Fortunately, Global InterSec LLC shed some light on the whole affair and
    revealed the malignant nature of the oversight to the world.

    Their results were applied to the latest OpenSSH versions by privately
    trained Mickey Mouse Hacking Squadron security specialists and revealed
    that the exploitation techniques developed by Global InterSec LLC are
    still applicable to the newest OpenSSH.

    PROOF OF CONCEPT
    - ----------------

    The following proof of concept is reproducing Global InterSec LLC
    findings, enhanced with the patented research performed by Mickey Mouse
    Hacking Squadron against OpenSSH 3.5p1.

    First of all, the OpenSSH 3.5p1 server has to be built (with PAM support
    enabled):

    $ tar xzf openssh-3.5p1.tar.gz
    $ cd openssh-3.5p1
    $ configure --with-pam
    [...]
    $ make sshd
    [...]

    Before the SSH server is actually executed, the sshd_config file should
    be modified in order to enable PAM ("PAMAuthenticationViaKbdInt yes").

    # sshd

    In order to reveal the nature of the OpenSSH vulnerability, the next
    step is to connect to the SSH server:

    $ ssh werewolf.research.mmhs.com
    Password:

    Thanks to the "Password:" prompt, it is clear that PAM is actually
    enabled (otherwise, the prompt would have been "user@host's password:").
    This unique fingerprinting technique was investigated by Mickey Mouse
    Hacking Squadron, and is already present in the latest version of the
    Mickey Mouse Hacking Squadron award winning network vulnerability
    assessment tool.

    After the previous command was executed, the freshly spawned sshd
    process has to be examined with a debugger, in order to set the correct
    breakpoints within the input_userauth_info_response_pam() function of
    OpenSSH, as demonstrated in the Global InterSec LLC advisory:

    # gdb sshd 6552
    (gdb) disassemble input_userauth_info_response_pam
    [...]
    0x80531bc <input_userauth_info_response_pam+192>: push %esi
    0x80531bd <input_userauth_info_response_pam+193>:
    call 0x807306c <xfree>
    [...]
    (gdb) break *0x80531bd
    Breakpoint 1 at 0x80531bd: file auth2-pam.c, line 158.
    (gdb) continue
    Continuing.

    Now that the buggy call to xfree() can be intercepted, the SSH client
    should trigger the integer overlow and the resulting heap overflow:

    $ ssh werewolf.research.mmhs.com
    Password: <type a thousand 'A' characters here and hit enter>

    After that, the xfree() breakpoint is reached, and the next call to
    free() should therefore be intercepted in order to comply with the
    technique developed by Global InterSec LLC:

    Breakpoint 1, 0x080531bd in input_userauth_info_response_pam (type=61,
    seqnr=7, ctxt=0x809c050) at auth2-pam.c:158
    158 xfree(resp);
    (gdb) disassemble xfree
    [...]
    0x807308e <xfree+34>: call 0x804ba14 <free>
    [...]
    (gdb) break *0x807308e
    Breakpoint 2 at 0x807308e: file xmalloc.c, line 55.
    (gdb) continue
    Continuing.

    Breakpoint 2, 0x0807308e in xfree (ptr=0x809dfb8) at xmalloc.c:55
    55 free(ptr);
    (gdb) x /10x 0x809dfb8
    0x809dfb8: 0x41414141 0x41414141 0x41414141 0x41414141
    0x809dfc8: 0x41414141 0x41414141 0x41414141 0x41414141
    0x809dfd8: 0x41414141 0x41414141

    >From here on, as demonstrated by Global InterSec LLC, exploitation
    becomes trivial. For more information on exploiting calls to free() see
    the excellent Phrack article "Once upon a free()" [2].

    WORK AROUND
    - -----------

    As mentioned in http://www.openssh.com/txt/preauth.adv, and as
    demonstrated by noir in http://www.phrack.org/phrack/60/p60-0x06.txt,
    "you can prevent privilege escalation if you enable
    UsePrivilegeSeparation in sshd_config."

    Love,

    - --
    Mickey Mouse Hacking Squadron
    -----BEGIN PGP SIGNATURE-----
    Version: Hush 2.2 (Java)
    Note: This signature can be verified at https://www.hushtools.com/verify

    wlkEARECABkFAj4XqFwSHG1taHNAaHVzaG1haWwuY29tAAoJEMZ9fu0iAPxbgYEAoL0W
    0oGQQvqwwZAGADonQ2TOUjNmAJ4zuUfANSpju97UjXdD65bkCy6M1A==
    =YvOU
    -----END PGP SIGNATURE-----
    By the sacred **** of the sacred psychedelic tibetan yeti ....We\'ll smoke the chinese out
    The 20th century pharoes have the slaves demanding work
    http://muaythaiscotland.com/

  2. #2
    Leftie Linux Lover the_JinX's Avatar
    Join Date
    Nov 2001
    Location
    Beverwijk Netherlands
    Posts
    2,535
    yet another reason to use ssh.com's non-commercial ssh instead of the openssh !

    http://www.ssh.com/support/downloads...ommercial.html
    ASCII stupid question, get a stupid ANSI.
    When in Russia, pet a PETSCII.

    Get your ass over to SLAYRadio the best station for C64 Remixes !

  3. #3
    Kwiep
    Join Date
    Aug 2001
    Posts
    924
    Do a vulnerability search on securityfocus.com and you'll find about 30 other reasons... or at least about 10 pretty new ones. I get plenty of openssh discuusion from the one or another mailinglist to not even bother using it... I don't need it either, my system is working fine.
    Double Dutch

  4. #4
    Senior Member
    Join Date
    Jul 2001
    Posts
    343

    Angry SSH

    Great!!!

    All I need to do is to figure out if all the Cobalt servers I admin
    has a SSH hole in it....
    Franklin Werren at www.bagpipes.net
    Yes I do play the Bagpipes!

    And learning to Play the Bugle

  5. #5
    Antionline's Security Dude instronics's Avatar
    Join Date
    Dec 2002
    Posts
    901
    Impressive, and thank you very much for posting this. This is really vital information for admins and anyone who uses ssh servers. Until i check my versions and tighten my security im closing my sshd. Thanx alot
    Ubuntu-: Means in African : "Im too dumb to use Slackware"

  6. #6
    Jaded Network Admin nebulus200's Avatar
    Join Date
    Jun 2002
    Posts
    1,356
    Just by quickly glancing over this article, it looks like to me it only effects OpenSSH that was compiled with PAM, or at least it looks like to me it takes advantage of playing around with PAM parameters to induce the overflow. Am I correct in this? Would I also be correct in assuming that without PAM, my versions would not be vulnerable?

    /nebulus
    There is only one constant, one universal, it is the only real truth: causality. Action. Reaction. Cause and effect...There is no escape from it, we are forever slaves to it. Our only hope, our only peace is to understand it, to understand the 'why'. 'Why' is what separates us from them, you from me. 'Why' is the only real social power, without it you are powerless.

    (Merovingian - Matrix Reloaded)

  7. #7
    Kwiep
    Join Date
    Aug 2001
    Posts
    924
    Big nice tip from me to all "admins and anyone who uses ssh servers": sign up for a mailing list like bugtraq or something. You would have know about this thing for about a month.
    Double Dutch

  8. #8
    Senior Member
    Join Date
    Apr 2002
    Posts
    1,049
    Yep nebulus200 you are correct
    (gdb) disassemble input_userauth_info_response_pam
    [...]
    0x80531bc <input_userauth_info_response_pam+192>: push %esi
    0x80531bd <input_userauth_info_response_pam+193>:
    call 0x807306c <xfree>
    [...]
    (gdb) break *0x80531bd
    Breakpoint 1 at 0x80531bd: file auth2-pam.c, line 158.
    (gdb) continue
    Continuing.

    Now that the buggy call to xfree() can be intercepted, the SSH client
    should trigger the integer overlow and the resulting heap overflow:
    you also need to type a thousand A's to get it to seg fault to get the call to the xfree() breakpoint
    By the sacred **** of the sacred psychedelic tibetan yeti ....We\'ll smoke the chinese out
    The 20th century pharoes have the slaves demanding work
    http://muaythaiscotland.com/

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •