J-Security Center

Latest Attack Object Updates
  • IDP Daily Update #1545
    posted: 11/19/09
  • NSM Daily Update #1545
    posted: 11/19/09
  • Deep Inspection 5.3r5 and above, 5.4, 6.0 #1545
    posted: 11/19/09
  • Deep Inspection 5.1 and 5.2 #1435
    posted: 11/19/09
  • Deep Inspection 5.0, 5.3r4 and below #1132
    posted: 03/28/08 (04/01/08 for 5.0)
  • Antivirus
    posted: 11/19/09

Title: IBM/Tivoli OPC Tracker Agent Multiple Vulnerabilities

Severity: HIGH

Description:

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. The following 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 were observed 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 attacks this allows, 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:
Similarly, 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" will show 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.

4.) Lack of operation logging:
OPC allows jobs to be sent 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.

Affected Products:

  • IBM Tivoli OPC Tracker Agent 1.0.0 X
  • IBM Tivoli OPC Tracker Agent 2.0.0 X
  • IBM Tivoli OPC Tracker Agent 3.0.0 x

References:

Juniper Networks provides this content via a wide variety of sources and production methods. If notified of errors or omissions in the content of this page, Juniper Networks, at its discretion, will modify or remove the page or leave the content as is, depending on various factors including but not limited to the reputation and authority of the party providing the notification. Please use the contact information displayed elsewhere on this page to report any errors or omissions regarding the content on this page.