Update: Hotfixes released for ODBC and OLE DB drivers for SQL Server

abhishekdwivedi798 That will cover you for drivers installed as part of a SQL Server installation. It won't cover clients that have installed the drivers separately.

I assume you mean different ODBC and OLEDB drivers altogether, versus different versions. Any MS ODBC Driver 17/18 for SQL Server or MS OLE DB 18/19 Driver for SQL Server prior to the versions above are vulnerable. I don't have a comprehensive list of other drivers.

DavidEngelMS  If we update the SQL version with the latest cumulative update currently available, it should resolve all the vulnerabilities related to OLEDB and ODBC drivers. However, do you believe there are any additional measures that need to be taken? Additionally, considering the size of our environment with thousands of SQL servers, this process seems to be an ongoing task. Do you happen to possess a list differentiating the ODBC and OLEDB drivers that have vulnerabilities from those that do not?

Tks for sharing

Marek_Belan Standalone ODBC updates are not planned for WSUS. SQL Server updates containing the ODBC drivers are already available there.

taozuhong Libraries are available for all of those languages: Connection libraries for Microsoft SQL Database - SQL Server | Microsoft Learn

And you can package ODBC directly. Huge is also pretty relative. 4.5MB for the Windows x64 installer (containing x64 and x86 binaries) and <1MB on Linux/macOS isn't huge by modern standards. If you really want to go smaller on Windows, you can forgo the Windows ODBC Driver Manager subsystem, just package the DLL (<2MB), and load the library directly from your app folder.

Regards,

David

SQLServer could provide a library that could use by C/C++/PHP/ODBC/Ruby/Nodejs/JDBC?

ODBC is not friendly for App, it can't package it directly, and it's a huge package and complex。

Is this updates come to WSUS ? 

jrauman 

This answer has some subtleties, so bear with me.

I don't own the old drivers, but from experience, I can confirm that file versions for the old ODBC drivers generally match the SQL Server version information.
See Latest updates and version history for SQL Server - SQL Server | Microsoft Learn.

Given your list, I noticed "13.3.x" doesn't match anything on that doc page, but Microsoft SQL Server Versions List lists 13.3.6300.2 as an alternate version number to 13.0.6300.2 under SQL Server 2016 SP3. I assume that website doesn't have the latest update and that 13.3.7024.30 corresponds to 13.0.7024.30 since everything but the minor version matches up to the latest SQL Server 2016 SP3 update release. Given the above, here's what your versions correlate to:

If all your ODBC driver installs are in the scope of a SQL Server install, all you need to do to update the drivers is apply the relevant SQL Server update.

If you have driver installs outside of the scope of a SQL Server install that you can't migrate to the latest 17/18 versions, you'll need to manually extract and install the appropriate msodbcsql.msi from the latest SQL Server updates as I described in my previous comment.

There is an additional scenario I'd like to describe for SQL Server installs. 13.x and 14.x are all valid file versions for "ODBC Driver 13 for SQL Server". "ODBC Driver 13 for SQL Server" was shipped with both SQL Server 2016 and SQL Server 2017. Within SQL Server 2016, "ODBC Driver 13 for SQL Server" is versioned 13.x. Within SQL Server 2017, "ODBC Driver 13 for SQL Server" is versioned 14.x. When updates are made to either of SQL Server 2016 or SQL Server 2017, you will get a newer 13.x or a newer 14.x. Both of which can be considered the "latest version" within their line. However, only one of them can be installed on a system at a time, unlike the other MS ODBC driver major versions. And a version 14.x ODBC driver will upgrade and replace a version 13.x ODBC driver. Given versioning semantics, I would assume any version 14.x driver will upgrade/replace even a newer 13.x driver. If a 14.x ODBC driver ever replaced a 13.x ODBC driver on a SQL Server 2016 system (tools like SSMS also install a version of the ODBC driver), it would functionally work fine, but a subsequent SQL Server 2016 update would not (I assume) patch the 14.x ODBC driver since the 14.x driver would be a newer version. Solutions for this scenario would be to manually update the 14.x ODBC driver or uninstall the 14.x driver and install the 13.x driver so that future SQL Server 2016 updates will patch it.

Regards,

David

I know ODBC 13 is being patched here, but how can we tell if our ODBC 13 installs are the absolute latest version?  I ran a software inventory and I have the following  "ODBC Driver 13 for SQL Server" versions:

What do these actually correlate to in terms of what I can download and install?  And can I bring them all to the latest version?  

Regardless of any vulnerabilities, if you are using a version of the ODBC driver less that 17 in an application outside of SQL Server, yes, I would update to ODBC 17. This does require that you are able to control the driver or connection string used by the application. If you can't control that, you will break your application when you uninstall ODBC 11/13 because the application will be looking for a driver with the old name (ODBC Driver 13 for SQL Server, for example).

For drivers older than ODBC 17 (ODBC 13, 11), those are updated/supported within the scope of a SQL Server installation. For example, in the CVEs from February, where the CVE lists SQL Server versions 2017 or older, if the ODBC driver was the source of the issue, you can expect it to be part of a SQL Server update package. While there will likely be no separate driver download for those old driver versions (I don't own the old ones, so I don't know if that will change), you can extract the driver package from the SQL update. Simply extract all files from a SQL update via `SQLServerXXXX-KBXXXXXXX-x64.exe -x`. Search the folder you extracted to for `msodbcsql.msi`.

Even I have detected - Microsoft SQL ODBC and OLE DB Driver Remote Code Execution (RCE) Vulnerability for April 2023

The ODBC Driver is 13. Can we expect a fix or should we update it to the latest drivers 17 or 18?