FYI Cheers, Domonkos Czinke
----- Original Message ----- From: <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> To: <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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> > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
