A dangerous privilege-escalation path exists in SQL Server when cross-database ownership chaining, system database defaults, and overly permissive permissions are combined. Under these conditions, a low-privilege authenticated user can escalate to sysadmin, gaining full control of the instance. This article walks through how an attacker can abuse these mechanics.<\/p>\n\n\n\n
Cross-database ownership chaining is a SQL Server<\/a> feature that controls how permissions<\/a> are evaluated when objects in one database access objects in another. When enabled, SQL Server may skip permission checks across database boundaries if object ownership conditions are met.<\/p>\n\n\n\n While this mechanism is essential for many built-in SQL Server features and system workflows, it introduces implicit trust relationships between databases. If these trust boundaries are misunderstood or combined with excessive permissions, they can be abused by an attacker to move laterally across databases and escalate privileges.<\/p>\n\n\n\n As documented<\/a> by Microsoft:<\/p>\n\n\n\n \u201cEnabling cross-database ownership chaining in SQL Server introduces a potential security vulnerability. When this feature is active, a local database user with elevated privileges can exploit ownership chaining to escalate permissions and potentially gain sysadmin<\/strong> access.\u201d<\/em><\/p>\n\n\n\n Understanding how SQL Server evaluates permissions is critical to correctly assessing both its legitimate uses and its potential for abuse.<\/p>\n\n\n\n It’s first important to understand how SQL Server evaluates permissions to avoid incorrect assumptions.<\/p>\n\n\n\n SQL Server uses ownership chaining<\/a> to determine whether permission checks on underlying objects can be skipped during execution. This mechanism allows users to interact with complex database logic, such as stored procedures<\/a> and views<\/a>, without requiring direct permissions on every underlying table.<\/p>\n\n\n\n When a stored procedure accesses an object in the same database, SQL Server evaluates permissions as follows:<\/p>\n\n\n This is known as an ownership chain. As long as the chain remains unbroken and all objects are owned by the same principal – commonly dbo (database owner) – SQL trusts the execution context and suppresses additional permission validation.<\/p>\n\n\n\n Here’s a practical example of how ownership chaining works in SQL Server:<\/p>\n\n\n\n Scenario<\/strong><\/p>\n\n\n First, create a login we\u2019ll use as our database owner and add it to the Now create a login we\u2019ll use as our app user:<\/p>\n\n\n\n Under the We’ll now create a table called ‘Salaries’ and a procedure that reads the table:<\/p>\n\n\n\n The result is as expected: However, ———– ———————<\/p>\n\n\n\n The execution succeeds despite This behavior is by design – so is not<\/em> considered a security flaw. In summary, this model allows SQL Server to safely expose data through controlled interfaces while preserving strict permission boundaries.<\/p>\n\n\n\n Now, let\u2019s analyze a scenario where the ‘Salaries’ table owner is the same, but the table is stored in a different database.<\/p>\n\n\n\n Create a new database called Now, back on And here’s what happens when By default, SQL Server enforces strict isolation between databases. Permissions granted in one database do not <\/em>automatically carry over to another, even if the same login owns objects in both.<\/p>\n\n\n\n Cross-database chaining can be used to enable this access. While powerful, this feature introduces security risks and is therefore disabled by default.<\/p>\n\n\n\n Let\u2019s enable it on both databases to see how it works:<\/p>\n\n\n\n Access to the ‘AppDB_HR’ table via the ———– ———————<\/p>\n\n\n\n As discussed earlier, cross-database ownership chaining is disabled<\/em> by default for user databases. This default protects database boundaries and prevents implicit trust relationships between separate databases. However, cross-database ownership chaining is enabled<\/em> by default on master, msdb, and tempdb<\/a> system databases.<\/p>\n\n\n\n While this behavior is necessary (many built-in procedures and features rely on cross-db object access between system DBs), it has important security consequences. This is because system databases are owned by sa<\/a> – and can’t be changed.<\/p>\n\n\n\n If a low-privilege user gains the ability to create or modify objects in one of these databases, they may be able to leverage cross-database ownership chaining to access or influence objects in another system database. Here’s why:<\/p>\n\n\nHow SQL Server evaluates permissions<\/h2>\n\n\n\n
\n
EXECUTE<\/code> permission on the stored procedure.
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\nHow ownership chaining works in SQL Server<\/h2>\n\n\n\n
\n
<\/li>\n\n\n\n
<\/li>\n\n\n\ndbcreator<\/code> server level role:<\/p>\n\n\n\nUSE master\nGO\nCREATE LOGIN AppDbOwner WITH PASSWORD = 'StrongPassword!123';\nGO\nALTER SERVER ROLE dbcreator ADD MEMBER AppDbOwner\nGO<\/pre><\/div>\n\n\n\n
CREATE LOGIN AppUser WITH PASSWORD = 'StrongPassword!123';\nGO<\/pre><\/div>\n\n\n\n
AppDbOwner<\/code> login context, create a database called ‘AppDB’ and a user for AppUser<\/code> inside the database. Notice that AppUser<\/code> has execute permission on dbo schema.<\/p>\n\n\n\nUSE master\nGO\nEXECUTE AS LOGIN = 'AppDbOwner';\nGO\nCREATE DATABASE AppDB;\nGO\nUSE AppDB\nGO\nCREATE USER AppUser FOR LOGIN AppUser;\nGO\nGRANT EXECUTE ON SCHEMA::dbo TO AppUser\nGO\nUSE master\nGO\nREVERT;\nGO<\/pre><\/div>\n\n\n\n
USE AppDB;\nGO\nEXECUTE AS LOGIN = 'AppDbOwner';\nGO\nCREATE TABLE Salaries\n(\n EmployeeID INT,\n Salary MONEY\n);\nGO\nINSERT INTO Salaries VALUES(1, 1000);\nGO\nCREATE PROCEDURE ReadSalaries\nAS\nBEGIN\n SELECT * FROM Salaries;\nEND;\nGO\nREVERT;\nGO<\/pre><\/div>\n\n\n\n
AppUser<\/code> does not<\/em> have access to the ‘Salaries’ table:<\/p>\n\n\n\nUSE AppDB;\nGO\nEXECUTE AS LOGIN = 'AppUser';\nGO\nSELECT * FROM Salaries;\nGO\nREVERT;\nGO<\/pre><\/div>\n\n\n\n
Msg 229, Level 14, State 5, Line 28
The SELECT permission was denied on the object 'Salaries', database 'AppDB', schema 'dbo'.<\/code><\/p>\n\n\n\nAppUser<\/code> CAN execute the ReadSalaries<\/code> procedure:<\/p>\n\n\n\nUSE AppDB;\nGO\nEXECUTE AS LOGIN = 'AppUser';\nGO\nEXEC ReadSalaries\nGO\nREVERT;\nGO<\/pre><\/div>\n\n\n\n
EmployeeID Salary<\/code><\/p>\n\n\n\n1 1000.00<\/code><\/p>\n\n\n\n(1 row affected)<\/code><\/p>\n\n\n\nAppUser<\/code> not having any direct permissions on ‘Salaries.’ Since dbo (AppDbOwner<\/code>) owns both the table and<\/em> the procedure, no permissions were checked.<\/p>\n\n\n\nWhy this behavior works – and is not<\/em> considered a security flaw<\/h4>\n\n\n
\n
AppDbOwner<\/code>)
<\/li>\n\n\n\nAppDbOwner<\/code>)
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\nEXECUTE<\/code> permission on the procedure is required<\/li>\n<\/ul>\n<\/div>\n\n\nFast, reliable and consistent SQL Server development…<\/h3>\n
How to add cross-database access to this scenario<\/h3>\n\n\n\n
AppDB_HR<\/code> and a ‘Salaries’ table on it. We\u2019re also creating a user for AppUser<\/code> on this database but will not<\/em> grant any permissions for it. Note that the AppDB_HR<\/code> database owner is the same as AppDB<\/code> (AppDbOwner<\/code>).<\/p>\n\n\n\nUSE master\nGO\nEXECUTE AS LOGIN = 'AppDbOwner';\nGO\nCREATE DATABASE AppDB_HR;\nGO\nUSE AppDB_HR\nGO\nCREATE USER AppUser FOR LOGIN AppUser;\nGO\nCREATE TABLE Salaries\n(\n EmployeeID INT,\n Salary MONEY\n);\nGO\nINSERT INTO Salaries VALUES(1, 1000);\nGO\nUSE master\nGO\nREVERT;\nGO<\/pre><\/div>\n\n\n\n
AppDB<\/code>, let\u2019s recreate the ReadSalaries<\/code> procedure to access the ‘Salaries’ table on the AppDB_HR<\/code> database:<\/p>\n\n\n\nUSE AppDB\nGO\nEXECUTE AS LOGIN = 'AppDbOwner';\nGO\nDROP PROC IF EXISTS ReadSalaries\nGO\nCREATE PROCEDURE ReadSalaries\nAS\nBEGIN\n SELECT * FROM AppDB_HR.dbo.Salaries;\nEND;\nGO\nREVERT;\nGO<\/pre><\/div>\n\n\n\n
AppUser<\/code> tries to execute the ReadSalaries<\/code> procedure:<\/p>\n\n\n\nUSE AppDB\nGO\nEXECUTE AS LOGIN = 'AppUser';\nGO\nEXEC ReadSalaries\nGO\nREVERT;\nGO<\/pre><\/div>\n\n\n\n
Msg 229, Level 14, State 5, Procedure ReadSalaries, Line 4 [Batch Start Line 128]
The SELECT permission was denied on the object 'Salaries', database 'AppDB_HR', schema 'dbo'.<\/code><\/p>\n\n\n\nALTER DATABASE AppDB_HR SET DB_CHAINING ON\nALTER DATABASE AppDB SET DB_CHAINING ON\nGO<\/pre><\/div>\n\n\n\n
ReadSalaries<\/code> procedure is now allowed:<\/p>\n\n\n\nUSE AppDB\nGO\nEXECUTE AS LOGIN = 'AppUser';\nGO\nEXEC ReadSalaries\nGO\nREVERT;\nGO<\/pre><\/div>\n\n\n\n
EmployeeID Salary<\/code><\/p>\n\n\n\n1 1000.00<\/code><\/p>\n\n\n\n(1 row affected)<\/code><\/p>\n\n\n\nExplaining the security implications of Cross DB ownership being enabled by default on master, msdb and tempdb<\/h2>\n\n\n\n
\n
<\/li>\n\n\n\nCONTROL<\/code>, ALTER<\/code>, or broad DDL<\/a> permissions on system databases is extremely<\/em> dangerous<\/li>\n<\/ul>\n<\/div>\n\n\nExplaining privilege escalation to sysadmin in SQL Server (cross-DB ownership and a SQL agent job)<\/h2>\n\n\n\n