Vulnerability Note VU#975403

Common Desktop Environment (CDE) ToolTalk RPC database server (rpc.ttdbserverd) does not adequately validate file descriptor arguement to _TT_ISCLOSE()

Original Release date: 11 Jul 2002 | Last revised: 19 Jul 2002

Overview

The Common Desktop Environment (CDE) ToolTalk RPC database server does not adequately validate a client-supplied argument, allowing attackers to overwrite certain locations in memory with zeros. This vulnerability could be exploited in a number of ways, potentially allowing attackers to: cause a denial of service, remotely delete arbitrary files, remotely create arbitrary directories, and potentially execute arbitrary code or commands.

Description

CORE SECURITY TECHNOLOGIES has reported a vulnerability in the CDE ToolTalk RPC database server (rpc.ttdbserverd). A component of CDE, the ToolTalk architecture allows applications to communicate with each other via remote procedure calls (RPC) across different hosts and platforms. The ToolTalk RPC database server manages connections between ToolTalk applications. CDE and ToolTalk are installed and enabled by default on many common UNIX platforms.

ToolTalk clients can close a ToolTalk database by issuing an RPC request to the database server. During this process, a call is made to the procedure _TT_ISCLOSE(), and a file descriptor argument supplied by the client is used to reference a memory structure that contains information about the requested ToolTalk database. A memory location within the structure is set to zero (0L), ostensibly closing the requested database. The ToolTalk database server does not check the range of the file descriptor, so it is possible to reference a location in memory that is outside the region that contains valid database information. As a result, a specially crafted RPC call can cause specific memory locations in the ToolTalk database server process space to be set to zero. By issuing such a call, and also by controlling the contents of memory through other means, attackers could exploit this vulnerability in a number of different ways.

Impact

The CORE SECURITY TECHNOLOGIES report describes several different attacks including remotely deleting arbitrary files and remotely creating arbitrary directory entries. In addition, attackers might be able to crash the ToolTalk RPC database server, denying service to legitimate users. It could be possible for attackers to execute arbitrary code and commands, although this has not yet been demonstrated. The ToolTalk RPC database server typically runs with root privileges.

Solution


Apply a Patch

When available, apply a patch from your vendor.


Disable rpc.ttdbserverd

Until patches are available and can be applied, you may wish to consider disabling the ToolTalk RPC database service. As a general best practice, the CERT/CC recommends disabling any services that are not explicitly required. The ToolTalk RPC database service may be enabled in /etc/rpc or in /etc/inetd.conf. On a Solaris 8 system, comment out the following entry in /etc/inetd.conf to disable the ToolTalk RPC database service (rpc.ttdbserverd):

#
# Sun ToolTalk Database Server
#
100083/1        tli     rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd rpc.ttdbserverd

The rpcinfo(1M) and ps(1) commands may be useful in determining if you system is running the ToolTalk RPC database server. On a Solaris 8 system, the following examples indicate that the ToolTalk RPC database server is running:

# rpcinfo -p | grep 100083
    100083    1   tcp   32773

# ps -ef | grep rpc.ttdbserverd
    root   355   164  0  19:31:27 ?        0:00 rpc.ttdbserverd

Block or Restrict Access

Until patches are available and can be applied, block or restrict access to the RPC portmapper service and the ToolTalk RPC database service from untrusted networks such as the Internet. Using a firewall or other packet-filtering technology, block the ports used by the RPC portmapper and ToolTalk RPC services. The RPC portmapper service typically runs on ports 111/tcp and 111/udp. The ToolTalk RPC service may be configured to use port 692/tcp or another port as indicated in output from the rpcinfo command. Keep in mind that blocking ports at a network perimeter does not protect the vulnerable service from the internal network. It is important to understand your network configuration and service requirements before deciding what changes are appropriate.

Systems Affected (Learn More)

VendorStatusDate NotifiedDate Updated
Compaq Computer CorporationAffected11 Jun 200209 Sep 2002
Hewlett-Packard CompanyAffected11 Jun 200215 Aug 2002
IBMAffected11 Jun 200211 Jul 2002
SGIAffected11 Jun 200207 Nov 2002
Sun Microsystems Inc.Affected11 Jun 200210 Jul 2002
The SCO Group (SCO UnixWare)Affected12 Jun 200213 Sep 2002
Xi GraphicsAffected12 Jun 200213 Jun 2002
FujitsuNot Affected12 Jun 200211 Jul 2002
Cray Inc.Unknown12 Jun 200224 Jun 2002
Data GeneralUnknown12 Jun 200213 Jun 2002
The Open GroupUnknown12 Jun 200211 Jul 2002
TriTealUnknown-12 Jul 2002
If you are a vendor and your product is affected, let us know.

CVSS Metrics (Learn More)

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A N/A

References

Credit

The CERT/CC thanks Ricardo Quesada and Iván Arce of CORE SECURITY TECHNOLOGIES for reporting this vulnerability.

This document was written by Art Manion

Other Information

  • CVE IDs: CAN-2002-0677
  • CERT Advisory: CA-2002-20
  • Date Public: 10 Jul 2002
  • Date First Published: 11 Jul 2002
  • Date Last Updated: 19 Jul 2002
  • Severity Metric: 9.47
  • Document Revision: 41

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.