|发布时间 :1998-10-02 00:00:00|
|修订时间 :2008-09-10 15:01:52|
[原文]IBM/Tivoli OPC Tracker Agent version 2 release 1 creates files, directories, and IPC message queues with insecure permissions (world-readable and world-writable), which could allow local users to disrupt operations and possibly gain privileges by modifying or deleting files.
[CNNVD]IBM/Tivoli OPC Tracker Agent多重漏洞(CNNVD-199810-007)
IBM/Tivoli OPC Tracker Agent版本2及发布的版本1存在漏洞。带有不安全许可(全域可读以及全域可写)的文件、目录和IPC消息队列被创建，本地用户通过修改或删除文件来中断操作并且可能获得根特权。
- CVSS (基础分值)
- CPE (受影响的平台与产品)
- OVAL (用于检测的技术细节)
(UNKNOWN) BID 382
(VENDOR_ADVISORY) BUGTRAQ 19981002 Several potential security problems in IBM/Tivoli OPC Tracker Age nt
|IBM/Tivoli OPC Tracker Agent多重漏洞|
|1998-10-02 00:00:00||2005-10-20 00:00:00|
|IBM/Tivoli OPC Tracker Agent版本2及发布的版本1存在漏洞。带有不安全许可(全域可读以及全域可写)的文件、目录和IPC消息队列被创建，本地用户通过修改或删除文件来中断操作并且可能获得根特权。|
|Currently the SecurityFocus staff are not aware of any vendor supplied patches for this issue. If you feel we are in error or are aware of more recent information, please mail us at: email@example.com.|
|IBM Tivoli OPC Tracker Agent Weak Permission Privilege Escalation|
Unknown or Incomplete
Unknown or Incomplete
|Unknown or Incomplete|
|IBM/Tivoli OPC Tracker Agent Multiple Vulnerabilities|
|Origin Validation Error||382|
|1998-10-02 12:00:00||2009-07-11 12:56:00|
|These vulnerabilties were posted to the Bugtraq mailing list by Dr. Klaus Kusche <Klaus.Kusche@OOE.GV.AT> Fri, 2 Oct 1998. The Discussion section of this vulnerability entry is almost wholly derived from that post.|
|IBM Tivoli OPC Tracker Agent 3.0 X
IBM Tivoli OPC Tracker Agent 2.0 X
IBM Tivoli OPC Tracker Agent 1.0 X
|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
* ... 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.
Currently the SecurityFocus staff are not aware of any exploits for this issue. If you feel we are in error or are aware of more recent information, please mail us at: firstname.lastname@example.org.
Currently the SecurityFocus staff are not aware of any vendor supplied patches for this issue. If you feel we are in error or are aware of more recent information, please mail us at: email@example.com.