Several potential security problems in IBM/Tivoli OPC Tracker Age

[Klaus.Kusche () OOE GV AT (Klaus.Kusche () OOE GV AT)]

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. My 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.

I observed the following potential problems with this product:

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 (I haven't checked what can
actually be done 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 I 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.

I didn't try what happens if this is really done repeatedly (the Tracker
Agent is installed on production machines only here, unsuitable for
experiments ...), but I guess 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 (I've successfully crashed AIX systems using a
small script with telnet in a loop against a similar listening-but-inactive
port).

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.


I did not yet investigate the network connection between the Tracker Agent
and the OPC master for vulnerabilities and the quality of the protocol used
(i.e. if it is possible to submit jobs or replace the actual OPC master by
tampering with that connection, or crash the Tracker Agent by sending large
amounts of garbage to it on that connection).


Even more surprising was the reaction of the IBM support when I opened a
call about 1., 3., and 4. (2. is new and has not yet been communicated to
IBM - it wouldn't help anyway I believe):

For 3., initially they didn't understand the problem at all - they forwarded
the call to the IBM AIX TCP/IP support group because they believed something
is wrong with AIX networking and not with their program. I believe they
understand what we are talking about after several explanations, but still
see no problem on their side.

For 1., they state that was done on purpose for easier testing and control
of the tracker's operation.

For all the above items, their last word is that everything works as
designed, there is no problem at all and hence nothing will be changed (we
were informed that we could open a change request...).

Some extracts from the IBM calls:

 according to the way it's designed, tracker can be run under different
 userids. The umask 666 has been chosen to allow a better visibility
 of the files produced during normal running. This also guarantees
 to the user a higher flexibility in handling and using these files.
 So far we never experienced security problems.
 What you are realizing is true. There might be some circumstances
 where a different umask would be preferable.
 If you believe that this is an important issue for you, please
 open a requirement to address it.

 we read carefully your and TCP/IP's people append. We understand
 your point of view but there's not much wecan do in order to help you.
 In fact, tracker is working as designed.
 The only thing you can do, if you believe it necessary, is to address
 your problem solution to the development team,opening a requirement,
 specifying clearly which are your requests.

If that's the way IBM/Tivoli cares for security...

DI. Dr. Klaus Kusche
Oberoesterreichische Landesregierung / Government of Upper Austria
Rechenzentrum / Computing Centre
Smail: Kaerntnerstrasse 16, A-4020 Linz, Austria (Europe)
Phone: +43 732 7720 - 3394   Fax: +43 732 7720 3198
Email: Klaus.Kusche () ooe gv at