Poniżej publikujemy list, który ukazał się na liście BugTraq, a z którego wynika, że w OpenSSH występuje poważny błąd. Jednak jak podano kilka chwil później, informacja o błędzie nie jest zgodna z prawdą. Dlatego szybko poprawiamy tę wiadomość i przepraszamy za ewentualne wprowadzenie was, drodzy czytelnicy, w błąd.

  UWAGA - INFORMACJA O BŁĘDZIE JEST NIEZGODNA Z PRAWDĄ  FOR ENGLISH-SPEAKING USERS - THIS MAIL IS FAKE    From mmhs@hushmail.com Mon Jan  6 20:25:42 2003  Date: Sat,  4 Jan 2003 19:37:03 -0800  From: mmhs@hushmail.com  To: bugtraq@securityfocus.com  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 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 :       push   %esi  0x80531bd :      call   0x807306c   [...]  (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:     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 :   call   0x804ba14   [...]  (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  

Archiwalny news dodany przez użytkownika: honey.
Kliknij tutaj by zobaczyć archiwalne komentarze.

Przeczytaj też

Oznaczone jako → 
Share →