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.Kuscheat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:18:34 PDT