TUCoPS :: Linux :: Apps A-M :: citrix.htm

Vulnerability
 Citrix Winframe
Affected
 Citrix Winframe client 3.x for Linux, Solaris
Description
 David Terrell found following. Presumably this holds true for the
 other unix clients as well, but it was tested only on linux. The
 Citrix Winframe linux client (used for accessing Winframe and
 Windows NT Server Terminal Edition) has a simple configuration
 section. Perhaps too simple.... All configuration information is
 stored in a directory /usr/lib/ICAClient/config which is mode 777.
 This in and of itself is bad news, since any user on the system
 can overwrite configuration data. The situation is actually much
 worse than that.
 When you start up the actual session manager (wfcmgr) you get a
 listbox of configured sessions. The data for this listbox is
 stored in the mode 777 file /usr/lib/ICAClient/config/appsrv.ini.
 So there's a single config file shared between all users. A
 sample session profile follows:
 [WFClient]
 Version=1
 [ApplicationServers]
 broken=
 [broken]
 WinStationDriver=ICA 3.0
 TransportDriver=TCP/IP
 DesiredColor=2
 Password=0006f6c601930785
 Domain=NTDOM
 Username=user
 Address=hostname
 Yep. Passwords are stored in some kind of hash. What that hash
 is doesn't really matter since you can just bring up wfcmgr and
 log in as that user. Terrible.
 This all said it's true for the "newer" UNIX clients -- e.g., 3.0
 for Solaris -- but not for older ones -- e.g., 2.6 for Solaris.
 On the newest version (3.0.15) of the ICA Client for Linux and
 found some differences. The /usr/lib/ICAClient dir is now mode
 755 which is good, but it keeps each users appsrv.ini in
 ~/.ICAClient now, which is mode 755 too, so still anyone can read
 the file.
 While we're on the matter Andy Polyakov added following.
 Background. ICA client lets you "mount" any UNIX directory as a
 drive within any particular WinFrame/MetaFrame session. Problem.
 Files created by Windows on such client-mapped drive appear to be
 world-writable. umask doesn't have no effect. Tracing system
 calls made by the client reveals that all newly created files are
 scrupulously chmoded to 777. Both 2.x and 3.x clients exhibit
 this behaviour. No, it doesn't mean a compromise, but one may
 find it totally inappropriate when such important security
 description as access permissions on newly created files is taken
 behind your back.
Solution
 Workaround? wfcmgr supports the -icaroot parameter, but you
 basically need to copy all the files in for it to work. So
 duplicate the tree in your home directory, fix permissions, and do
 wfcmgr -icaroot $HOME/.ica
 You may not need to duplicate all files. With older clients it's
 possible to duplicate only the files the user has to be able to
 change -- e.g., the three .ini files in .../config -- and use
 symbolic links to the rest. Also consider using the older clients
 and disabling the acceptance of the password at the server. Since
 the newer clients also seem to fall back to a ~/.ICAClient
 sub-directory, it might be possible to delete the world-accessible
 directories and files (partial success in test). Alternatively,
 don't use it.
 Workaround for Andy's problem (for platforms supporting dynamic
 linking) should be following. Compile following "module" as a
 shared object and make run-time linker preload it (e.g. by setting
 LD_PRELOAD on Linux and Solaris and
 _RLD_LIST=${ICAROOT}/chmod.so:DEFAULT on IRIX).
 int chmod(){return 0;}
 Side effects. If you have version 3.x and a user runs the client
 for the very first time, initial config files are copied from
 ${ICAROOT}/config and they (files) inherit 444 access permissions.
 To workaround this chmod u+w ${ICAROOT}/config/* (files in
 ${ICAROOT}/config are owner by root anyway).