[NT] Visual SourceSafe - Preliminary Observations
From: email@example.com To: firstname.lastname@example.org Date: 1 Jan 2003 10:16:14 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
Beyond Security would like to welcome Tiscali World Online
to our service provider team.
For more info on their service offering IP-Secure,
please visit http://www.worldonline.co.za/services/work_ip.asp
- - - - - - - - -
Visual SourceSafe - Preliminary Observations
A comparison between Visual SourceSafe and other version control programs
have revealed some fundamental flaws in the way VSS works, the flaws and
their possible solution are illustrated below.
Visual SourceSafe is barely network aware. By "barely", it is network
aware in the same way an Access Database can be network aware - all
program logic is on the client side, including access control, while the
server contains only data (represented as files - there is no daemon or
service on the server).
This in itself may not be a problem for some environments.
However, the installation instructions tell the administrator to create a
share for the VSS data files, and to give access to "Everyone" for those
files. In some shops this may be acceptable, but it should not be in most.
At the very least, "Authenticated Users" would be a better choice. Even
better would be to limit it to those users who actually need access.
Second, within a "project", you can not effectively control access. While
the user interface lets you set permissions for different files, these
permissions are validated by the client, not the server. Thus, anyone who
reverse-engineers the client or, perhaps, anyone with access to the VSS
data files (Joel is not sure if they are encrypted; if they are, it is
with a shared key hard-coded into the client) has access to the entire
project. Basically, the security user interface provides a way to "advise"
a client that he doesn't have access to a file. The only real security is
NTFS permissions, which, unfortunately, must apply to the entire project,
not individual project files/directories. To me, this is a case of "bad
security is even worse then no security"!
1) Lock down the share's permissions to only those with a "need to know"
2) Don't bother with the security interface of VSS
3) Put data with different security requirements in different projects
4) Note that anyone with access to those data files (every developer for
the project!) can modify version history with custom-written tools
This means that the version history tracking cannot be used to support
audit functionality, as history can be changed by a knowledgeable
attacker. There is no server enforcing the rule, "Only add new versions,
and keep old ones" - this is done by the client. For users using the VSS
client only, it is probably true. But any program could in theory access
these files, including a hacker tool which allowed for changing history
(for instance, to slip a bug into the next version by making it look like
a particular code file has not changed in this version; thus that piece of
code is not reviewed by others).
The information has been provided by <mailto:email@example.com> Joel
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: firstname.lastname@example.org
In order to subscribe to the mailing list, simply forward this email to: email@example.com
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Next message: firstname.lastname@example.org: "[NEWS] Citibank (Canada) Internet Explorer Miss-configuration"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]