Potential vulnerability in SCO TermVision Windows 95 client

[nexus () PATROL I-WAY CO UK (JJ Gray)]

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 ?