COMMAND

    IBM/Tivoli OPC Tracker Agent

SYSTEMS AFFECTED

    Any system running IBM/Tivoli OPC Tracker Agent (AIX for sure)

PROBLEM

    Klaus Kusche found  following.  The  IBM/Tivoli OPC Tracker  Agent
    is a  product which  allows jobs  to be  scheduled and executed on
    Unix systems under the control of  an OPC master on an IBM  MVS or
    Unix host.   Klaus's observations were  made on the  Tracker Agent
    version 2 release  1 for AIX,  but most likely,  the same problems
    are present in the IBM/Tivoli OPC Tracker Agents for Sun,  Digital
    Unix, ...  The Tracker Agent is a set of several daemon processes,
    at least one of them communicating  over the net.  If jobs  are to
    be executed under different  userids, some of these  processes are
    installed suid root.

    The following potential problems with this product were observed:

    1.) File and directory permissions
    ==================================

        The Tracker Agent sets the permissions of all files it creates
        during  operation  to  666,  i.e.  world  read- and writeable.
        Moreover, if  tracker jobs  are to  be executed  under several
        different  userids,  the  working  directories  of the Tracker
        Agent must  be readable  and writeable  by all  these userids,
        which means in practice that they must be mode 777 (at  least,
        it didn't work with anything less here).

        Hence, we end up with:
        * Suid root daemon programs.
        * ...requiring their working directories to be world-writeable
          (moreover,  the  default  name  of  the  dir  is .../tmp, so
          anyone  searching  for  tmp  directories  to  play with will
          easily find it).
        * ...creating   files  with   absolutely  predictable    names
          (sequentially numbered!)  in these  directories, usually  at
          predictable times (when OPC jobs are scheduled).
        * ...giving these files mode  666, no matter what umask  is in
          effect.

        Apart from  all the  usual tricks  this allows  (no tests with
        symlinks etc.), the following points are worth noting:
        * One of the 666 files  (in fact, even 777) is the  job (shell
          script) to be executed. If one managed to modify such a file
          or prepare one in advance, he could have arbitrary  commands
          executed under some different userid (possibly root).
        * Another 666 file is the output of the job. This file is kept
          permanently, it is not  cleaned up after processing  the job
          has finished.  Hence,  if your jobs produce  sensitive data,
          better don't use OPC, or  your data will just sit  there and
          invite anyone to read and modify...
        * At least, it should  be possible to severely interfere  with
          the Tracker Agent's operation by removing files in the wrong
          moment, pre-creating files it cannot open or overwrite, ...

    2.) IPC permissions
    ===================

        Similarely,  the  Tracker  Agent  creates  several IPC message
        queues, also with mode 666 (r/w by everyone).

    3.) Listening network port
    ==========================

        According  to  "netstat  -a",  the  AIX  OPC  tracker   client
        permanently  listens  on  tcp/localtracker  (port  5011 on our
        system).   However,  it  does  not  seem  to  process incoming
        connections to this  port: They hang  around forever.   If you
        telnet to that port, type a few characters (or pipe a  chargen
        to the  telnet), and  quit or  kill the  telnet, "netstat  -a"
        shows   that   connections   in   the   state   "ESTABLISHED",
        "CLOSE_WAIT" or "FIN_WAIT_1" remain  ad infinitum, one or  two
        per individual telnet, with up to 32K buffer space occupied in
        each  direction  ("CLOSE_WAIT"  for  typing  a  few  chars and
        quitting, the others for a piped chargen and killing).  Even a
        simple TCP connect  portscan ("strobe") causes  one connection
        per scan to  be queued up  permanently in the  kernel.  "lsof"
        does not show any processes connected to these connections, it
        lists  just  a  single  tracker  process  corresponding to the
        established connection to the MVS OPC master.  There is no way
        to free these kernel ressources again except for stopping  and
        restarting the OPC tracker.  It was not tested what happens if
        this is  really done  repeatedly, but  the guess  is that this
        behaviour leads to denial-of-service attacks (TCP/IP slowdown,
        out  of  mbufs,  system  crash?),  even across the net without
        having a local userid.

    4.) Operation logging
    =====================

        OPC  allows  to  send  jobs  from  other hosts on the network,
        executing them under the  userid (possibly root) specified  on
        the remote host.   However, nothing gets  logged in the  usual
        ways, neither  in syslog  or sulog,  nor in  wtmp, nor  in any
        other standard places.  If your rules of the house require all
        remote executions or all changes of uids to be logged, you are
        out of luck.

SOLUTION

    Hm, it seems  that IBM/Tivoli see  this as feature(!?)  so be loud
    with them.