{"vuid":"VU#850785","idnumber":"850785","name":"Sun KCMS library service daemon does not adequately validate location of KCMS profiles","keywords":["kcms_server","arbitrary remote file retrieval","no authentication","RPC","solaris","sun","kcms","kodak color management system","profile","kcms library service daemon","tooltalk","ttdbserverd","tt_db","_tt_isbuild"],"overview":"The Sun KCMS library service daemon, kcms_server, does not adequately validate the location of KCMS profile files. This could allow a remote attacker to read arbitrary files on a vulnerable system.","clean_desc":"Sun Solaris contains support for the Kodak Color Management System (KCMS), an application programming interface (API) that provides color management functions for different devices and color spaces. From the KCMS Application Developer's Guide:  \"The KCMS framework enables the accurate reproduction, and improves the appearance of, digital color images on desktop computers and associated peripherals.\"  KCMS profiles contain information that \"tell[s] the KCMS framework how to convert input color data to the appropriate color-corrected output color data.\"  The KCMS framework \"loads and saves profiles, gets and sets KCMS profile attributes, and directs requests for color management to the right CMM at the right time.\"\nFrom the man page for kcms_server(1): <pre> DESCRIPTION\n     The kcms_server is a daemon that allows the KCMS library  to\n     access  profiles on remote machines. The KCMS library is its\n     only client. Profiles can be accessed read only and must  be\n     located  in  the following directories. This is for security\n     reasons. /usr/openwin/etc/devdata/profiles\n        /etc/openwin/devdata/profiles kcms_server will be automatically started by inetd(1M)  when\n     a  request  to use the server is generated by a remote host. An entry has been added to /etc/inet/inetd.conf  correspond-\n     ing to kcms_server that makes this possible. </pre> As part of the KCMS framework, the KCMS library service daemon (kcms_server) provides a way to serve KCMS profiles to remote clients. The daemon is implemented as a Sun remote procedure call (RPC) service that is managed by the Internet services daemon (inetd(1M)) and the RPC portmapper service (rpcbind(1M)). The KCMS library service daemon listens for network requests and serves read-only KCMS profiles from /etc/openwin/devdata/profiles and /usr/openwin/etc/devdata/profiles. A typical request for a KCMS profile specifies the name of the file (fileName) and optionally, its location (hostName). When opening a profile, the KCMS library service daemon does not adequately validate the fileName argument. According to a report published by Entercept, the checks performed by the KCS_OPEN_PROFILE procedure are not complete in that they do not account for the case of a sub-directory within the KCMS profile directories. If an attacker is able to create a sub-directory within either of the directories searched by the KCMS library service daemon, the attacker could use a specially crafted fileName argument that would bypass the directory traversal checks and allow the attacker to read any file on a vulnerable system. As noted by Entercept, the ToolTalk database server (rpc.ttdbserverd(1M)) procedure _TT_ISBUILD() can be used to create a directory named TT_DB in an arbitrary location on a remote system. The KCMS library service daemon runs with root privileges, and both it and the ToolTalk database server are typically installed and enabled by default on Solaris systems.","impact":"A remote attacker could read any file on a vulnerable system. In the example described by Entercept, an attacker would first need to create a directory under /etc/openwin/devdata/profiles or /usr/openwin/etc/devdata/profiles.","resolution":"Apply Patch When available, apply the appropriate patch as referenced by Sun.","workarounds":"Disable kcms_server Until patches are available and can be applied, disable the KCMS library service daemon by commenting out the appropriate entry in /etc/inetd.conf, terminating any currently running kcms_server processes, and restarting the Internet services daemon inetd(1M). The rpcinfo(1M), netstat(1M), and ps(1) commands may be useful in determining if the KCMS library service daemon is enabled. The following examples are from a SunOS 5.8 (Solaris 8) system: [/etc/inetd.conf] # Sun KCMS Profile Server 100221/1        tli     rpc/tcp wait root /usr/openwin/bin/kcms_server  kcms_server The KCMS library service is assigned RPC program number 100221. $ rpcinfo -p |grep 100221\n    100221    1   tcp  32781 $ netstat -a |grep 32781 *.32781                               Idle\n      *.32781              *.*                0      0 24576      0 LISTEN $ ps -ef |grep kcms_server root   484   156  0 15:12:01 ? 0:00 kcms_server As a general best practice, the CERT/CC recommends disabling any services that are not explicitly required. Block or Restrict Access Until patches are available and can be applied, block or restrict access to the RPC portmapper service and the KCMS library service daemon from untrusted networks such as the Internet. The RPC portmapper service typically runs on ports 111/tcp and 111/udp. In the above example, the KCMS library service daemon is configured to run on 32781/tcp, however, this port number may vary. Also, consider blocking or restricting access to the ToolTalk database server (RPC program number 100083). 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.","sysaffected":"","thanks":"This vulnerability was \nreported\n by Sinan Eren of \nEntercept","author":"This document was written by Art Manion.","public":["http://www.entercept.com/news/uspr/01-22-03.asp","http://docs.sun.com/db/doc/816-1325/6m7oiipal?q=kcms_server&a=view#profiles-2","http://docs.sun.com/db/doc/816-1325/6m7oiipat?q=kcms_server&a=view#datastructs-18","http://www.iana.org/assignments/sun-rpc-numbers"],"cveids":["CVE-2003-0027"],"certadvisory":"","uscerttechnicalalert":null,"datecreated":"2002-11-01T21:00:14Z","publicdate":"2003-01-22T00:00:00Z","datefirstpublished":"2003-01-22T17:55:27Z","dateupdated":"2003-04-14T16:04:17Z","revision":56,"vrda_d1_directreport":"","vrda_d1_population":"","vrda_d1_impact":"","cam_widelyknown":"1","cam_exploitation":"0","cam_internetinfrastructure":"4","cam_population":"14","cam_impact":"8","cam_easeofexploitation":"13","cam_attackeraccessrequired":"15","cam_scorecurrent":"2.0475","cam_scorecurrentwidelyknown":"9.828","cam_scorecurrentwidelyknownexploited":"18.018","ipprotocol":"","cvss_accessvector":"","cvss_accesscomplexity":"","cvss_authentication":null,"cvss_confidentialityimpact":"","cvss_integrityimpact":"","cvss_availabilityimpact":"","cvss_exploitablity":null,"cvss_remediationlevel":"","cvss_reportconfidence":"","cvss_collateraldamagepotential":"","cvss_targetdistribution":"","cvss_securityrequirementscr":"","cvss_securityrequirementsir":"","cvss_securityrequirementsar":"","cvss_basescore":"","cvss_basevector":"","cvss_temporalscore":"","cvss_environmentalscore":"","cvss_environmentalvector":"","metric":2.0475,"vulnote":null}