When SQL Server Security Falls Between Documentation, Disclosure, and Vulnerability

Microsoft campus, Redmond. Photo by the author.
The article reflects my personal views on SQL Server security research, documentation, and coordinated disclosure.

The recent public discussion around YellowKey and Microsoft’s vulnerability disclosure process has put vulnerability research, coordinated disclosure, and Microsoft’s Security Response Center (MSRC) into the spotlight.   While that specific discussion is about Windows and BitLocker, it exposes a broader problem that many researchers recognize: vulnerability disclosure is often framed as a simple responsibility of the researcher.

The idealized workflow is straightforward: find the issue, report it, wait for the vendor, and accept the outcome.

But coordinated disclosure cannot be a one-way obligation.

If researchers are expected to invest serious time, understand the product deeply, document complex behavior, build a reproducible proof of concept, sometimes even create a video, wait for triage, and then live with whatever decision the vendor makes, then the vendor side also has responsibilities.   That includes product-specific review, clear reasoning, timely communication, and transparent disclosure when security-relevant behavior changes.

To be clear, MSRC does not have an easy role.  Microsoft has to evaluate reports across a vast product portfolio, protect customers on a global scale, and avoid releasing information that could increase risk before fixes are broadly available.  But that makes product-specific review and clear communication more important, not less.

My own focus is Microsoft SQL Server, Microsoft’s flagship database platform.  SQL Server rarely becomes the center of public vulnerability debates, but given the critical role of an RDBMS in enterprise environments, and the recent increase in findings from independent researchers, it is worth looking at how these disclosure challenges appear there as well.

For customers, this is not only a researcher-process issue.  SQL Server security depends heavily on documented permission boundaries, role semantics, and servicing behavior.  If those change silently, organizations may continue relying on assumptions that are no longer true.  In enterprise environments, those assumptions often lead to role assignments, approved exceptions and the base for audit decisions.

SQL Server issues often do not look like classic vulnerabilities

Let’s start with this: Many SQL Server security findings do not look like obvious vulnerabilities at first glance.

They are not always remote unauthenticated code execution or missing authorization.
Vulnerabilities in SQL Server often involve combinations of permissions, roles, ownership chaining, system stored procedures, SQL Agent and other subsystems.

A generic vulnerability process may look at a finding and conclude:

“Requires role membership.  ”
“Requires permission X.  ”
“Looks like documented behavior.  ”
“Looks like intended behavior.  ”

But they may still miss the security impact.

In SQL Server, much like in any other system the question is not only which permission is required.  It is also what practical power that permission gives the user, how commonly it is assigned, and whether the resulting behavior still matches the boundary customers and administrators reasonably expect.

That is not always easy to determine.

For example, SQL Server does not have a built-in method that reliably answers the question: “What can this principal practically do if it holds this permission?”

The effective allowed actions challenge
The reason is that access control in SQL Server is not action-based, it is permission-based.  The permission model is deep, old, and highly composable.  Hardly anyone has the full model in their head.  I believe I know it reasonably well, and still there are situations where the interaction is not obvious until it is tested.

But that is where many interesting SQL Server findings live.

The researcher’s work

Before submitting a serious SQL Server report, a researcher typically has to reproduce the behavior across multiple versions, compare CU and GDR levels, isolate the minimum required permission set, and account for configuration differences that affect reproducibility.

That work alone can take many hours or days.

The researcher then has to explain the escalation path, document expected and observed behavior, and provide a proof of concept that is clear enough for review.  For SQL Server permission issues, that often means explaining not only what happened, but why the behavior crosses a boundary that customers would reasonably expect to exist.

The asymmetry in vulnerability handling

Once a report enters the vendor process, the balance changes.

The vendor controls the case status, severity assessment, and bug-bar interpretation.  The vendor decides whether the issue is fixed, documented, deferred, downgraded, or closed.  The vendor controls the advisory wording, whether a CVE is issued, whether the researcher is acknowledged, and whether a bounty is paid.

The researcher can provide evidence, answer questions, refine the proof of concept, and argue the security impact.  But the final decision usually belongs to the vendor.

That asymmetry is not inherently wrong.  Vendors own their products, understand their servicing constraints, and must balance many customer-risk considerations that may not be visible from the outside.  But the asymmetry does create a responsibility to explain decisions clearly, especially when a researcher has submitted a detailed, product-specific escalation analysis.

This becomes particularly important when the final outcome is one of the familiar gray-zone conclusions: low severity, does not meet the bar, will be documented, will not be fixed, or no CVE.  Some of those outcomes may be correct.  Not every report is a vulnerability, and some reports really do describe documented or intended behavior.

The problem starts when the reasoning is too thin to show that the product-specific attack path was understood.  For SQL Server, that matters because the impact is often not obvious from the prerequisite permission alone.  A finding may require a role or permission, but the relevant question is whether that role or permission was intended to cross the security boundary that the behavior now crosses.

If the explanation does not address that boundary question, researchers are left guessing whether the issue was rejected on its merits or because the impact was not fully understood.  Over time, that weakens trust in the process.

 

SQL Server triage needs SQL Server context

In my opinion, SQL Server permission issues cannot be reviewed only by looking at the prerequisites.

A meaningful review should also consider:

• What can the user do after obtaining this permission or role?
• What is the documented intent of the assigned permission and roles?
• Would customers reasonably treat it as below sysadmin or db_owner?
• Does the behavior cross a boundary that the product or documentation implies should exist?
• How would a customer learn about a change of the security model for the task in question?

This is also how Fabiano Amorim, who has reported multiple SQL Server security issues, put the technical challenge this way:

“After spending time doing SQL Server security research, I have learned that a specific permission or role does not tell the whole story.  It is the starting point of the analysis, not the conclusion.  The question I ask myself for every feature, prerequisite, or permission is whether it creates a practical attack path across an expected security boundary.  SQL Server’s security model is powerful, but compatibility requirements, old features, ownership chaining, system procedures, SQL Agent, impersonation, and trusted execution contexts can interact in unexpected ways.  ”

This is important to consider for the documentation as well.  A documentation warning can help customers understand risk, but it does not automatically resolve the underlying security question.  If a role exists to provide delegated administration below sysadmin, customers will reasonably treat it as a boundary.  If that role can become a practical path to sysadmin, the boundary no longer holds.  Documenting that risk does not preserve the purpose of the role; it tells customers that the role should not be treated as lower-privileged in any meaningful security sense.

 

Recent examples: The ##MS_DatabaseManager## role, spatial helper procs

A recent example is the ##MS_DatabaseManager## role, which turned out to be a direct EoP path to sysadmin: ##MS_DatabaseManager## Privilege Escalation (Part 2): The Ownership-Based Security Model

The role is not sysadmin.  It exists to delegate database-management capabilities without giving full server control.

That is the point of its existence.

But if membership in that role creates a practical path to sysadmin under real conditions, the question is no longer simply whether some broad warning exists somewhere in the documentation.
The question becomes whether customers can safely treat the role as less privileged than sysadmin in the way the product design and documentation still imply.

If a role exists, someone looking for a role lower than sysadmin will assign it.

Another example is the recent documentation update for the spatial helper system procedures sp_help_spatial_geography_histogram and sp_help_spatial_geometry_histogram, which now state that membership in the sysadmin fixed server role is required.

According to Fabiano Amorim, who reported the original issue, the procedures already required sysadmin to complete successfully without errors.  However, the vulnerable injected code path could still execute before the procedure later failed.  In other words, sysadmin was required for a clean successful execution of the full procedure, but not for the security-relevant injected code to run.  (Read more in my June update to this list: The challenges for least privilege: When sysadmin is still required in Microsoft SQL Server)

That distinction is another example why SQL Server findings can be difficult to classify from prerequisites alone.  Looking only at the documented requirement may suggest that the procedure is restricted to sysadmins only.  But the actual execution path showed that security-relevant injected code could run before the procedure later failed.

Microsoft later updated the documentation to reflect the sysadmin requirement.  That may have corrected the documented prerequisite, but it did not make the security relevance obvious to customers.  If a system stored procedure involved in a security fix has this kind of execution-path nuance, customers and defenders should not have to reconstruct the meaning of the change from documentation diffs, blog posts, and post-fix behavior.

If a system stored procedure was hardened because it could be abused, the release notes and documentation should make the security relevance clear enough for customers to act.  For security relevant changes we have CVEs.  No such notification channel was used here.  The KB entry only stated generically that the vulnerability was fixed.

Documentation is a core component of the security model

For complex products, documentation is not just a manual.  It is part of the security model.

It may explicitly draw the line between what security controls the vendor handles and what configuration security the buyer must implement.  It serves as the source of truth for threat modeling.

DBAs, architects, auditors, consultants, and security teams use documentation to decide what is safe to delegate.  It is used to define least privilege.  To justify role assignments.  And to evaluate whether a finding is expected, acceptable, or a violation of policy.

If documentation says or implies that a role is suitable for a delegated task, customers will use it that way.

Silent documentation changes

That is why silent documentation changes are a problem.

If Microsoft changes documentation to say that a role can potentially elevate privileges, that may be useful for future readers.  But unless there is a CVE, a release-note entry, or another official announcement, many customers will never know that the security expectation has changed.

The same applies when system procedures suddenly require higher privileges, or when a formerly available path is quietly closed.  Without a clear announcement, customers may not realize that the permission model they relied on has changed, or that an existing role assignment now carries a different risk than they previously understood.

For researchers, there is another issue.  If behavior changes silently, or if release notes do not clearly connect the fix to the reported issue, it becomes difficult to understand whether the change was the result of one’s report or whether a different issue was independently found.  That affects trust in the process.

At the same time, I understand that a vendor has to consider risks that may not be visible to the researcher.  A vulnerability may point to related weaknesses with even greater impact.  If too much information is disclosed before customers have had a realistic opportunity to patch, the consequences can extend beyond individual customers and become a national-level risk.  That is why vendors often operate under a “minimum necessary disclosure” policy.

The difficult part is finding the right balance.  Responsible disclosure should not require full public details on day one, but it does require enough clarity for researchers and customers to understand what changed, why it matters, and whether their own security assumptions need to be revisited.

Coordinated disclosure goes both ways

Security researchers are often told to report issues responsibly.

That is fair.  Researchers should not ignore customer risk.  Publishing exploit details before customers have a reasonable way to protect themselves can cause harm.

But disclosure is not only something researchers do.

Vendors also disclose, or choose not to disclose.

When Microsoft silently changes documentation, changes privilege requirements, closes an escalation path, or hardens system procedures without a clear security note, that is also a disclosure decision.

Customers may not know that anything security-relevant changed.  Researchers may not know whether their report was understood.  Other defenders may continue operating under old assumptions.

Coordinated disclosure should not only mean that researchers coordinate with the vendor.

It should also mean that vendors communicate security-relevant changes clearly enough for customers and defenders to act.

What would help

In my opinion, for SQL Server specifically, several things would improve the process.

• Severity evaluation should consider the expected behavior of a permission or role. If a documented role can become sysadmin, the starting point should not automatically define the issue low impact.
• Documentation and servicing should be aligned. If a role or permission combination is not intended to be a security boundary, say that clearly.  Contained Availability Groups are a good example where the documentation explicitly calls out that they are not a security boundary.
• If a role or permission combination is intended to be a security boundary, then escalation paths across that boundary should be treated accordingly.
• Release notes should make security-relevant behavior changes easier to map. Customers and researchers should not have to reverse-engineer whether a CU or GDR fixed a reported issue, a related issue, or only one visible symptom.
• Closure decisions should include enough reasoning to be useful. A simple “Does not meet the bar” may be administratively efficient, but it does little to maintain trust when the researcher submitted a detailed, product-specific escalation analysis.

None of this requires treating every report as critical.

It requires treating SQL Server security research as SQL Server security research.

Why this matters beyond researchers

This may sound like a researcher-process issue, but it is ultimately also a customer issue.

Customers depend on vendors to evaluate security reports correctly.  They depend on CVEs, advisories, release notes, documentation, and servicing decisions to understand their exposure.

Emad Al-Mousa, a security researcher who has reported findings across major database platforms including SQL Server and Oracle, made a similar point from the customer-impact side:

“External researchers should be treated as real partners, especially when they spend time analyzing a critical product such as SQL Server.  Findings that are classified as low impact can still represent real security concerns for customers, particularly when they affect visibility, auditing, or the protection of sensitive data.  When those issues are dismissed without sufficient explanation or documentation updates, customers may never understand the risk.  ”

If permission changes are buried in documentation without a notification process, customers have little chance to realize that the burden has shifted to them.

If researchers lose trust in the reporting process, some issues may be disclosed less responsibly, sold elsewhere, or never reported at all.

None of those outcomes is good for defenders.

Final thought

Researchers should be expected to act responsibly.  Vendors should also be expected to handle responsible research with enough depth, transparency, and product knowledge to make the process worth trusting.

Coordinated disclosure should protect customers.  To do that, it must respect both sides of the process: the work required to find and explain issues, and the customer need to understand when security assumptions have changed.

Stay secure
Andreas