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 <mattscat_private> 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 ?
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:41:15 PDT