Security Bulletin: IBM® Db2® is vulnerable to remote code execution caused by installing like-named jar files across multiple databases. (CVE-2023-27859)

Summary

IBM® Db2® is vulnerable to remote code execution caused by installing like-named jar files across multiple databases. A user could exploit this by installing a malicious jar file that overwrites the existing like-named jar file in another database.

Vulnerability Details

CVEID:CVE-2023-27859
**DESCRIPTION:**IBM Db2 could allow a remote user to execute arbitrary code caused by installing like named jar files across multiple databases. A user could exploit this by installing a malicious jar file that overwrites the existing like named jar file in another database.
CVSS Base score: 6.5
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/249205 for the current score.
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N)

Affected Products and Versions

10.5.0.x

|

Server

IBM® Db2®|

11.1.4.x

|

Server

IBM® Db2®|

11.5.x

|

Server

All platforms are affected.
Earlier releases (10.1, 9.7 etc.) may also be affected, but they are no longer supported.

Note: Only instances with more than one database are affected.

One can check for possibility of shared JAR file names on your instance by issuing the following query in all the databases and checking if there are any common JARSCHEMA/JAR_ID combinations that are shared across databases:

select JARSCHEMA, JAR_ID from sysibm.SYSJAROBJECTS ORDER BY JARSCHEMA, JAR_ID

Remediation/Fixes

Customers running any vulnerable fixpack level of an affected Program, V10.5, v11.1 and V11.5, can download the special build containing the interim fix for this issue from Fix Central. These special builds are available based on the most recent fixpack level for each impacted release: V10.5 FP11, V11.1.4 FP7, and V11.5.9. They can be applied to any affected fixpack level of the appropriate release to remediate this vulnerability.

AIX 64-bit
HP-UX 64-bit
Linux 32-bit, x86-32
Linux 64-bit, x86-64
Linux 64-bit, POWER™ big endian
Linux 64-bit, POWER™ little endian
Linux 64-bit, System z®, System z9® or zSeries®
Solaris 64-bit, SPARC
Solaris 64-bit, x86-64
Windows 32-bit, x86
Windows 64-bit, x86

V11.1| TBD| DT196678| Special Build for V11.1.4 FP7:

AIX 64-bit
Linux 32-bit, x86-32
Linux 64-bit, x86-64
Linux 64-bit, POWER™ little endian
Linux 64-bit, System z®, System z9® or zSeries®
Solaris 64-bit, SPARC
Windows 32-bit, x86
Windows 64-bit, x86

V11.5| TBD| DT196678|

Special Build for V11.5.0:

AIX 64-bit (for OS7.1)

Special Build for V11.5.8:

AIX 64-bit
Linux 32-bit, x86-32
Linux 64-bit, x86-64
Linux 64-bit, POWER™ little endian
Linux 64-bit, System z®, System z9® or zSeries®
Windows 32-bit, x86
Windows 64-bit, x86

Special Build for V11.5.9:

AIX 64-bit
Linux 32-bit, x86-32
Linux 64-bit, x86-64
Linux 64-bit, POWER™ little endian
Linux 64-bit, System z®, System z9® or zSeries®
Windows 32-bit, x86
Windows 64-bit, x86

IBM does not disclose key Db2 functionality nor replication steps for a vulnerability to avoid providing too much information to any potential malicious attacker. IBM does not want to enable a malicious attacker with sufficient knowledge to craft an exploit of the vulnerability.

To overcome the vulnerability issue with installation of JAR files, the location of the installed JAR file is made unique to with database, schema (and associated tenant) within the database. Introducing the database in the path ensures the jars are stored separately for each database, hence resolving the potential issue of overwriting and/or unauthorized access of JAR files across database.

Note that this solution continues supporting the earlier path **<instancepath>/function/jar/<schema>**where the JAR files exists before it upgrade to new solution. In more detail:

With user applying a level that contains to the new solution, JAR files can exist in two locations. Before upgrade the JAR files were stored at**:
<instancepath>/function/jar/<schema>
**They will would be continue to be available at same location. Newly installed jars will be stored at the new location:

<instancepath>/function/jar/<database>/<tenant>/<schema>.

This solution provides read and execution of the jars from both the location. As it does not expect any intervention from customer side, upgrade does not possess any impact to the customer.

If a customer would like to move an existing JAR files to the new location, the customer should issue the following command:

"CALL SQLJ.RECOVERJAR(‘<jarschema>.<jarid>’)

This will place the JAR file in the new path.

Workarounds and Mitigations

If your instance has multiple databases, then ensure that JAR files for each database are installed in separate schemas (i.e. there is no overlap in the schemas used for JAR files across all the databases).