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).