[10677] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Citrix Winframe client for Linux

daemon@ATHENA.MIT.EDU (Vic Abell)
Mon May 31 16:47:45 1999

Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <000a01bea951$08595570$e19ed280@vic3.cc.purdue.edu>
Date: 	Fri, 28 May 1999 16:28:31 -0500
Reply-To: abe@purdue.edu
From: Vic Abell <abe@PURDUE.EDU>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <19990528122659.A2279@pianosa.catch22.org>

David Terrell writes (in part):
>
> [ presumably this holds true for the other unix clients as well, but
>   all I have is linux to test on ]

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.

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

We have refused to install the Solaris 3.0 client for this
reason and have opened a case with Citrix about this and
other objectionable aspects (non-security ones). Those who
have Citrix support contracts, the case number is 23117500,
and you're welcome to join your complaints to ours.

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

It can be made not quite that easy.  The administrative
controls on the server end allow you to disable acceptance
of any stored passwords.  That has always been true, and
we have always done that, no matter where the clients were
designed to store passwords.

Of course, that doesn't mean people can't try to store
passwords -- it just means they won't be usable.

> Terrible.

Yes, the newer Citrix clients are most unlikable.

> I tried mailing both support@citrix.com and security@citrix.com but
> neither of these addresses exist.

The best you can do without a support contract is post a
complaint to their "forum," reachable via www.citrix.com.

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

> Alternatively, don't use it.

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.  I've been able to do that, but only with
partial success.

> Distressing that the company that was "bringing multiuser
> concurrent logons
> to Windows NT" makes such a little effort at understanding multiuser
> security.... [further editorialization left to the reader]

I believe Citrix tried to make it easier for people to generate
their own configurations and didn't understand the security
implications of what they were doing.  It's too bad they so sadly
compromised the secure use of their reasonably good product.

home help back first fref pref prev next nref lref last post