The ToolTalk session daemon ttsession does not properly check client credentials.
The insufficient check can lead to compromise of a system both locally and remotely with the credentials of the user running ttsession. Note that ttsession is not a system daemon and may not be running all the time. It is normally started as part of an X-session. Also, client programs of ttsession may restart the daemon if it isn't running.
Credit:
This vulnerability has been found by: Job de Haas.
The ttsession daemon is part of the ToolTalk toolkit and allows applications to send messages to each other. This is achieved by RPC calls. The RPC calls are not properly authenticated.
When sniffing a tt_open request to a remote host the following can be seen:
This shows how first the NULL procedure of ttsession is called and next a procedure with number 400. Then procedure 18 and 11 are called. The contents of the reply to the PROC=400 call is something like:
This is also described in the man page for ttession(1).
When this strings is looked at more closely, some aspects can be recognized. The number 1289637086 for example is the RPC program number (Solaris 7). Also, the IP of the remote host can be seen (10.0.0.10). The number 18176 is the PID of the ttsession process and 1000 is the uid of the user running ttsession.
When playing around with the RPC call to retrieve this string from ttsession, it has been discovered that it doesn't need client credentials to match the user that is running ttsession. Thus anyone can retrieve this string from a ttsession daemon.
This, combined with the discovery that the string is used by the tt_open call to determine the remote ttsession to connect to leads to the exploit code below. This code uses a message to invoke a dtpad on the host running ttsession. By using some tricks, it makes sure the dtpad is displayed on the requested DISPLAY.
Reason why the exploit may fail:
When a dtpad has been display on a X-server, it will keep a lock on that server until the dtpad -server process on the remote host has been terminated. Until that time no other dtpads from different hosts can be displayed on that Xserver. Close the X session and log back in again and try again.
Possible Workaround:
This problem has only been detected when the ttsession daemon is running with Unix RPC authentication flavor. This is the default. With options this can be changed to, for example, secure-RPC (DES). With CDE it can be configured in /usr/dt/bin/Xsession.
Affected systems:
ttsession has been part of OpenWindows (SunOS 4.1.x and Solaris), CDE (Solaris, AIX, HP, OSF/Digital) and IRIX.
It looks like most systems running CDE are vulnerable, although it was only verified on the following systems:
