                                                           January 3, 1999


                         Corruptio Optimi Pessima
                 "corruption of the best is worst of all"



   Vulnerability: Automountd
   Operating System: SUN Solaris
   Versions affected: 2.5, 2.5.1, 2.6, 2.7 (X86 and SPARC architectures)



 [ Rant -------------------------------------------------------------- ----

   You pay for this?  Why is it vendors can't get the hint?  Network users
   demand secure software, not poor attempts at patching longstanding holes
   in the current revisions.  Sun was warned about this bug years ago, and
   over time all they could come up with is a single broken patch that reminds
   us of the first Microsoft fix for the port 139 OOB attack.  Why does it
   take vendors like Sun over three MONTHS to patch this kind of hole?
   They claim that it takes that long because of the level of testing they
   must put the software through.  Right.  So not only do they supply a 
   broken patch, they test it for three months and never notice it is still
   vulnerable, then release it to their paying customers.

   You pay for this?  How many security vendors knew about this and said
   nothing?  Why did CERT never report this?  Why have hackers been passing
   these exploits around for two years?  Why didn't the ueber-spies of the
   ICSA get their hands on this and report it?  Why didn't Sun's own 
   "security analysis team" of 70 people find this bug (or any others)?
   Could it be job security?  We think so.

 ---- ------------------------------------------------------------------- ]


 [ Details ----------------------------------------------------------- ----

   Back in 1995, a vulnerability was discovered and a new world of buggy 
   software born. This particular bug, would be conceived when Sun 
   Microsystems made the foolish decision to ship Solaris 2.5 to customers.

   Since then, it has been a downhill roller coaster for the boys and girls 
   at SUN. Now, not only is 2.5 affected, but 2.5.1 stock, 2.5.1 patched, 
   2.6 and 2.7 are all affected as well.

   This bug is particularly important, because it shows the incompetence
   of Sun Microsystems.  Not only do they sit on patching bugs for months
   at a time, they cant even patch bugs right!

   When exploit code for the local automountd problem was leaked a few
   YEARS ago, SUN developed a patch and labeled it #104654-05.  However,
   intrestingly enough, even after the patch was released, this bug
   could still be exploited quite trivially.

   What SUN decided todo, was remove the 'popen' call and put in its place
   an 'execve' call.  Absolutely brilliant.  Did they forget that
   the variable holding the program and arguments to be execued could
   still be set by issuing a AUTOFS_MOUNT call to automountd?  Or,
   is this a case of job security by one of Sun's engineers?  We certainly
   feel it is the latter.

   Either way, not only is this bug local, but it is remote too!
   And, not only is it remote, but it is started by default as well!

   Yes, thats right boys and girls, you can now execute any program
   you like on any default installation of SUN remotely!  When exploiting
   this vulnerability, be sure to send SUN your warmest compliments.

   Now, getting back to the bug at hand, a few things have to be established
   before this can be exploited.

   First of all, to remotely exploit this bug, it becomes two-pronged.
   Meaning, we are now going to introduce another remote bug in the
   SUN Solaris operating system that when combined with the previous,
   create a lethal combination.

   This new bug, located in rpc.statd which is also started by default
   (imagine that!), allows for remote packets to be bounced to the local
   Operating System.

   Looking back at the details of automountd, we remember that it cannot
   accept packets on UDP or TCP protocols.  But, it can accept packets on
   the TLI protocol, which rpc.statd happens to forward to, allowing us 
   to remotely execute commands by sending our packets to rpc.statd.

   So, with all this in mind, if we send two RPC packets to rpc.statd on 
   Solaris 2.5, 2.5.1 stock, 2.5.1 patched, 2.6, or 2.7, with the SM_MON
   and SM_NOTIFY commands, rpc.statd will happily forward the packet
   on to the local operating system's automountd daemon.

   Variables we will have to setup will be the following:

   struct mon monr;
   struct status stat;

   memset(&monr, 0, sizeof(struct mon));

   monr.mon_id.my_id.my_name = cache;
   monr.mon_id.my_id.my_prog = (unsigned long)AUTOFS_PROG;
   monr.mon_id.my_id.my_proc = (unsigned long)AUTOFS_MOUNT;

   mon_id.my_id.my_name will be our cache, which we will be using to
   tell rpc.statd where to forward the packets to.

   The cache of the remote system can be found by establishing a connection
   to port 23, or port 21 of the system.  The cache will usually appear inside
   parentheseis, and will be the hostname of the machine.

   Another example of obtaining the cache, would be to lookup the ip address
   of the machine and use the hostname that comes back.

   For example, for pathetic.sun.com, you could try 'pathetic' or
   'pathetic.sun.com', and it will be a pretty safe bet that you will 
   pick the correct hostname.

   mon_id.my_id.my_prog will be the variable AUTOFS_PROG telling rpc.statd
   which RPC service to connect to.

   mon_id.my_id.my_proc will be the variable AUTOFS_MOUNT telling rpc.statd
   to tell automountd that we want a AUTOFS_MOUNT request.

   Further variables to setup:

   monr.mon_id.my_id.my_vers = 1;  /* For Solaris 2.5, 2.5.1 */
   or
   monr.mon_id.my_id.my_vers = 2;  /* For Solaris 2.6, and 2.7 */

   monr.mon_id.mon_name = command;
   stat.mon_name = command;

   monr.mon_id.mon_name and stat.mon_name will both contain the program
   to execute on the remote system.
   
   Now, with those variables setup, we can send off our RPC packets
   to the remote system.

   However, to complicate things more, we must modify our tekneeq of
   exploiting this bug, for it to succeed on 2.6 and 2.7.

   Because SUN implements a new function called SMHASH in rpc.statd on
   Solaris 2.6 and 2.7, we will now have to involve DNS spoofing
   to acomplish executing our command.

   Because of the way SMHASH works and the way RPC arguments are encoded,
   our command is what SMHASH attempts to lookup in its address tables
   once rpc.statd receives our packet.

   If SMHASH cannot detect if our command is a valid address, it will
   not forward the packet.  However, if we DNS spoof our command off
   the Primary and Secondary nameservers of the remote system, SMHASH
   will return true for finding the command as an address and our
   packet will be forwarded.

   If you wish to test this bug without DNS spoofing, you can also
   modify the /etc/hosts file on the Solaris system and put in the
   command you want to execute (without arguments) as a hostname
   with an ip address, and it will accomplish the same affect.

   For the actual exploit code to do this, I will let the reader go on
   to the next section to find it.

   Examples:

   If pathetic.sun.com were a Solaris 2.7 machine with pathetic
   as its hostname, and a vulnerable Primary name server,
   an exploit attempt would look like this:

   Execute commands to spoof reboot off Primary NS here
   ./amountdexp pathetic.sun.com pathetic reboot 1

   If pathetic.sun.com were a Solaris 2.5.1 machine with pathetic
   as its hostname, an exploit attempt would look like this:

   ./amountdexp pathetic.sun.com pathetic reboot 0

 ---- ------------------------------------------------------------------- ]


 [ Exploit ---- ------------------------------------------------------ ----

   Exploit code for this vulnerability can be easily obtained from the
   following URL: http://www.attrition.org/hosted/cop/index.html
 
 ---- ------------------------------------------------------------------- ]
