NT HACKS - MS Access Exploit

INF: Changes in Security in Microsoft Access Version 2.0

MS KB Article ID: Q112121
Creation Date: 07-NOV-1995
Revision Date: 19-SEP-1996

Original article is here: http://www.microsoft.com/kb/articles/q112/1/21.htm

The information in this article applies to:

Microsoft Access version 2.0

SUMMARY

Advanced: Requires expert coding, interoperability, and multiuser skills.

This article describes the changes in the Microsoft Access security model from version 1.x to version 2.0.

MORE INFORMATION

The security model is essentially unchanged from version 1.x to version 2.0. The following internal items are changed in version 2.0 security:

The SID column of the MSysACEs table is no longer directly readable through the Microsoft Access user interface. This prevents users from directly reading the user SIDs and using them to breach security. To view and update permissions, you must use Access Basic.
In Microsoft Access version 1.x, users had permission to open any database that was not protected by the file system. In Microsoft Access version 2.0, there are two new database-level permissions to control this: Open/Run and Open Exclusive. You can use the Open/Run permission to lock unauthorized users out of your database entirely. You can use the Open Exclusive permission to prevent users from inadvertently locking each other out of multiuser applications by opening the database exclusively.
As in Microsoft Access 1.x, once a user has opened a database there is no way, using the user interface, to prevent that user from creating new objects in the database. However, you can use Access Basic code to prevent users from creating new tables or queries in a database by revoking permissions on the Tables Container object.
The Microsoft Access 2.0 Setup program uses only the user and company names as seeds for the Admins group's SID. The version 1.x Setup program uses the user and company names, as well as the serial number from the installation disks.
Query permissions can cross database boundaries. This means you can use owner's permissions security with attached tables, as well as with local tables. The Run With Owner's Permissions query property in version 1.x has been replaced in version 2.0 by a query property called RunPermissions that can be set to User's or Owner's.
There was a known and documented hole in Microsoft Access version 1.x security whereby an unauthorized user could read a SID from a database and paste it over a SID in the MSysAccounts table in the SystemDB, thereby masquerading as a different user. The following changes were made to version 2.0 security to correct this problem:
```
    - System tables in version 2.0 are not updatable.
```
```
    - The SID columns in the MSysACEs and MSysObjects tables are

      unreadable in version 2.0.
```
```
    - The file encryption algorithm is enhanced. SIDs are readable by

      members of the Admins group only, and are not writable at all in

      version 2.0.
```
Microsoft Access version 2.0 can run version 1.x databases, but they are still vulnerable to the version 1.x security hole. This is so that sites can run a mixed environment, with some users running Microsoft Access version 2.0 and others running Microsoft Access version 1.x. Microsoft Access version 2.0 cannot make changes to security in a version 1.x database unless the database is converted to version 2.0 format.

Administrators of version 1.x sites that are upgrading to version 2.0 should be aware that in order to prevent unauthorized users from exploiting the version 1.x security hole to break into a secure version 2.0 system, it is necessary to re-create user and group accounts with the new longer PIDs, and to reassign permissions. If this is not done, it is possible for an unauthorized user to read a user's SID from an old version 1.x copy of the database and paste it over their own account's SID using Microsoft Access version 1.x and a version 1.x SystemDB. If the users' SIDs are re-created using Microsoft Access version 2.0, there is no way for an unauthorized user to ever read a user's SID.

If you are not concerned about the possibility of an unauthorized user exploiting the 1.x security hole to break into a secure version 2.0 system (perhaps because you are using security only to protect well- meaning users from inadvertently destroying data or applications, rather than protecting yourself from unauthorized intrusion), then you do not need to re-create your user and group accounts. Version 2.0 security will work properly with the old SIDs. Although the security in Microsoft Access version 2.0 is enhanced to protect your databases from unwanted intrusion, Microsoft recommends that you convert your databases to use version 2.0 security.

When you are using the Microsoft Access 2.0 Upgrade disks to upgrade an existing version 1.0 or 1.1 installation to version 2.0, a new SystemDB is created. The old SystemDB is not changed in any way. If you want to use your old SystemDB and your old SIDs, use the Workgroup Administrator to join your old workgroup.
In Microsoft Access version 1.x, the Guests group is given read permissions on all objects by default. In Microsoft Access 2.0, the Guests group has no default permissions on newly created objects.

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.