CVE-2024-39677: NHibernate-Core SQL Injection Vulnerability

CVE-2024-39677 Overview

NHibernate, a popular object-relational mapper for the .NET framework, contains a SQL injection vulnerability in certain types implementing the ILiteralType.ObjectToSQLString interface. This vulnerability affects multiple areas of the framework including inheritance mappings with discriminator values, HQL queries referencing static application fields, and direct use of SqlInsertBuilder and SqlUpdateBuilder utilities with literal value overloads.

Critical Impact

Successful exploitation allows attackers to execute arbitrary SQL commands through the ORM layer, potentially leading to complete database compromise, data exfiltration, and unauthorized data manipulation in .NET applications using affected NHibernate versions.

Affected Products

• NHibernate Core versions prior to 5.4.9
• NHibernate Core versions 5.5.x prior to 5.5.2
• Applications using ILiteralType.ObjectToSQLString methods directly

Discovery Timeline

• July 8, 2024 - CVE-2024-39677 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2024-39677

Vulnerability Analysis

This SQL injection vulnerability (CWE-89) exists in NHibernate's type system, specifically in the implementation of ILiteralType.ObjectToSQLString methods. The flaw allows malicious input to bypass proper SQL escaping mechanisms, enabling attackers to inject arbitrary SQL commands through the ORM abstraction layer.

The vulnerability is particularly concerning because it affects core ORM functionality that developers typically trust for safe SQL generation. Applications become exposed through several common usage patterns: inheritance mappings using discriminator values, HQL queries that reference static fields, and direct usage of SQL builder utilities with literal values.

Root Cause

The root cause lies in inadequate input sanitization within the ObjectToSQLString methods of types implementing ILiteralType. When converting literal values to SQL string representations, special characters—particularly backslashes and other escape sequences—were not properly escaped before being incorporated into SQL queries. This allowed specially crafted input to break out of string contexts and inject malicious SQL commands.

Attack Vector

This vulnerability is exploitable over the network without requiring authentication or user interaction. An attacker can inject malicious SQL through:

1. Discriminator values in inheritance mappings where user-controlled data influences discriminator selection
2. HQL queries that reference static fields populated from external input
3. SqlInsertBuilder/SqlUpdateBuilder calls using the AddColumn overload that accepts literal values derived from user input
4. Direct ObjectToSQLString calls where application code passes untrusted data

The security patch introduces proper handling for backslash escaping in string literals, as shown in the configuration changes:

                             </para>
                         </entry>
                     </row>
+                    <row>
+                        <entry>
+                            <literal>escape_backslash_in_strings</literal>
+                        </entry>
+                        <entry>
+                            Indicates if the database needs to have backslash escaped in string literals.
+                            The default value is dialect dependant. That is <literal>false</literal> for
+                            most dialects.
+                            <para>
+                                <emphasis role="strong">eg.</emphasis> 
+                                <literal>true</literal> | <literal>false</literal>
+                            </para>
+                        </entry>
+                    </row>
                     <row>
                         <entry>
                             <literal>show_sql</literal>

Source: GitHub Commit b4a69d1a5ff5744312478d70308329af496e4ba9

Detection Methods for CVE-2024-39677

Indicators of Compromise

• Unusual SQL queries containing escape sequences or unexpected SQL syntax in application logs
• Database error logs showing malformed queries or SQL syntax errors originating from NHibernate operations
• Evidence of unauthorized data access or modification through the ORM layer
• Anomalous database activity patterns following web requests with special characters in input fields

Detection Strategies

• Review application logs for SQL injection patterns in NHibernate-generated queries, particularly those involving string literals with backslash characters
• Implement database query monitoring to detect anomalous SQL patterns or unauthorized data access
• Audit code for usage of ObjectToSQLString methods, SqlInsertBuilder, and SqlUpdateBuilder with user-controlled input
• Deploy web application firewalls (WAF) with rules targeting SQL injection payloads in requests processed by .NET applications

Monitoring Recommendations

• Enable detailed logging for NHibernate query generation to identify potentially malicious inputs
• Monitor database audit logs for unusual query patterns or privilege escalation attempts
• Implement runtime application self-protection (RASP) to detect SQL injection attempts at the application layer
• Set up alerts for database errors that may indicate exploitation attempts

How to Mitigate CVE-2024-39677

Immediate Actions Required

• Upgrade NHibernate Core to version 5.4.9 or later for the 5.4.x branch
• Upgrade NHibernate Core to version 5.5.2 or later for the 5.5.x branch
• Audit all code paths using ILiteralType.ObjectToSQLString, SqlInsertBuilder, or SqlUpdateBuilder with user-supplied data
• Implement input validation on all data that may be used in discriminator values or HQL queries

Patch Information

NHibernate has released security patches in versions 5.4.9 and 5.5.2 that address this SQL injection vulnerability. The fix introduces proper escaping of special characters, including backslashes, in string literals through a new dialect-dependent configuration option escape_backslash_in_strings. For complete details, see the GitHub Security Advisory GHSA-fg4q-ccq8-3r5q and the GitHub Pull Request #3547.

Workarounds

• Avoid using ObjectToSQLString methods directly with untrusted input until patched versions can be deployed
• Implement strict input validation and sanitization for any data that flows into HQL queries or inheritance discriminators
• Use parameterized queries where possible instead of literal value methods
• Consider implementing a custom ILiteralType with proper escaping as a temporary measure

# Update NHibernate via NuGet Package Manager Console
Update-Package NHibernate -Version 5.5.2

# Or for .NET CLI
dotnet add package NHibernate --version 5.5.2