Date: Wed, 31 Mar 1999 16:50:13 +0100
From: JJ Gray <nexus@PATROL.I-WAY.CO.UK>
To: BUGTRAQ@netspace.org
Subject: Potential vulnerability in SCO TermVision Windows 95 client


Hi folks,
        I recently downloaded a trial version of the SCO TermVision 
terminal emulation package for SCO Openserver 5 and Windows 95 (
http://www.sco.com/vision/products/termvision/ ).   This comes
in two parts, the server based binaries and the Windows 95 client,
TermVision 2.1.   In addition to the terminal emulation you get 
'UNIX Neighborhood' which once supplied with a hostname, username &
password gives an explorer/X-Windows style interface to the SCO server.
In the default configuration the hostnames, usernames & passwords are 
saved in a file : C:\Windows\Profiles\%username%\Application
Data\SCO\Vision\Auth\%username%.vca
( PC is Windows 95, NT4 server, user profiles ).  The data is encrypted
but, not being a cryptanalysist, it took me a good 15 minutes to 
discover the encryption is nothing more than a fixed string XOR :(
I informed SCO of this on 30th March and received a reply the next day :)
--
>From Matthew Schofield, Support <mattsc@sco.com>

JJ,

Thanks for highlighting this issue in the Vision Comms.

By your own definition it is insecure, in that the contents of the .vca
files can be obtained with some effort. In terms of actually using 
someone's .vca file through the comms layer in order to access the UNIX 
resources through a Vision product, the files can only read by the
comms layer if the user has successfully logged into Windows as that user.
--
Extracted from my reply -

This is of no consequence.   The point is that I can extract the UNIX
username & password from another user that has used the same PC.
If that user happens to use root access then I have the root password -
thus a non privileged user with windows access can gain root privs on
the UNIX box, whether through UNIX Neighborhood, terminal emulation,
 a terminal itself, telnet etc.   If I were a windows user with no user
account on the UNIX box......... :)
--
When adding a host, the security options can be set to 'Prompt' where the
password is not saved.   Yes this is only a potential security hole - 
another on the 'Configuration' issue, but it is not obvious that this 
vulnerability exists.   The default is insecure and there is no 'obvious' 
information in the documentation that it is so - hence my post.
Matthew finished by saying
--
As you have already identified, you should change the password mechanism
for your host to prompt. In a future release we intend to either change 
the operation of the password mechanism or add an appropriate warning.
--
Can't really say fairer than that I suppose...

Regards,
        JJ Gray


Sed quis custodiet ipsos custodes ?

