OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS
FYI
Cheers,
Domonkos Czinke
----- Original Message -----
From: <mmhs@hushmail.com <mailto:mmhs@hushmail.com>>
To: <bugtraq@securityfocus.com <mailto:bugtraq@securityfocus.com>>
Sent: Sunday, January 05, 2003 4:37 AM
Subject: OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> *********** OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS ***********
>
> MICKEY MOUSE HACKING SQUADRON ADVISORY #2
>
> DISCLAIMER
> - ----------
>
> The nation's zeroth private security intelligence firm, Mickey Mouse
> Hacking Squadron uniquely addresses the challenges faced by both public-
> and private-sector organizations in protecting critical information
> assets.
>
> Our intelligence is timely, delivered 24 x 7, 365 (*) days per year;
> relevant, fully customizable, and actionable intelligence is only
> valuable if it makes a difference.
>
> (*) in the case of a leap year, we of course provide a 24 x 7, 366 days
> premier service.
>
> TECHNICAL BACKGROUND
> - --------------------
>
> The following advisory is based on the excellent advisory published by
> Global InterSec LLC *six months ago*:
>
> <http://www.globalintersec.com/adv/openssh-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 <mailto: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-----
>
>
>
>
> Concerned about your privacy? Follow this link to get
> FREE encrypted email: <https://www.hushmail.com/?l=2>
>
> Big $$$ to be made with the HushMail Affiliate Program:
> <https://www.hushmail.com/about.php?subloc=affiliate&l=427>
>
>
>
Reply to: