[NT] Visual SourceSafe - Preliminary Observations

From: support@securiteam.com
Date: 01/01/03

  • Next message: support@securiteam.com: "[NEWS] Citibank (Canada) Internet Explorer Miss-configuration" 
    From: support@securiteam.com
To: list@securiteam.com
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
    ------------------------------------------------------------------------

    SUMMARY

    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.

    DETAILS

    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"!

    Joel's recommendations:
    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).

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:jmaslak@antelope.net> Joel
    Maslak.

    ========================================

    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: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

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

    Relevant Pages