Category: Security

Andreas Wolter shares some thoughts:

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.

Andreas shares some perspective from having been a top security person on the SQL Server team. Along the way, he hits one on of my bugbears: the fact that there is no easy way to tell exactly what login X (or user X) can do on a SQL Server instance. The closest I ever got was to impersonate user X and run sys.fn_my_permissions() in the context of that user. But even that isn’t perfect.

Greg Low looks for an answer:

I saw a question on a SQL Server mailing list about how to determine the Windows groups for a given SQL Server login.

That’s actually easy for a sysadmin login, as they have IMPERSONATE permission for other logins/users.

It does require the ability to impersonate, as Greg mentions. If you don’t have that ability and you’re dealing with an Active Directory user, I could recommend: net user /domain {ActiveDirectoryUserName} in a command prompt to start.

Vlad Drumea explains how powerful a few specific roles are:

Privilege escalation is a method in which an attacker gains unauthorized privileged access into a system.
This is done by exploiting misconfigurations, design flaws or unpatched vulnerabilities.

The most straightforward example in SQL Server land being someone “promoting themselves” from members of the public fixed server role, to members of the sysadmin role.

Read on for these three roles and what you can do with them.

Fabiano Amorim describes a security concern:

This article describes a restore-boundary weakness involving indexed views. An attacker prepares a database backup on an attacker-controlled instance, tampers with the persisted definition of an indexed view, and delivers that database through an otherwise ordinary backup-and-restore workflow.

After the restore, SQL Server evaluates the preserved metadata during indexed-view optimizer-driven execution. Data from databases the attacker cannot directly query may still be pulled into the attacker’s own restored database through trusted internal processing paths. This is a clear cross-database confidentiality problem.

It’s an interesting post. The scope of damage is somewhat limited considering that the attacker would need legitimate permissions to the instance, but something to keep in mind nonetheless.

Lukas Vileikis covers the consequences:

In late 2024, a message by Nathan Bossart hit the database spotlight. Within it, he proposed a “multi-year, incremental approach to remove MD5 password support from PostgreSQL.”

Before we dive in completely, let’s establish one important thing first: what exactly is MD5?

One thing I strongly disagree with: Lukas’s comment that “A decade or so ago, when computing power was far smaller than it is now, MD5 was considered an ‘okay’ hashing mechanism.” There were MD5 rainbow tables readily available 15 years ago and people already realized MD5 was not good for password hashing, even with a salt. To the extent that these platform vendors thought it was “okay” a decade ago, they were already way out of date.