Address CVE-2025-59250: Fix spoofing vulnerability in JDBC Driver for SQL Server due to improper input validation and update version to 12.6.5 #2805
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR includes:
Problem Statement
The MSSQL JDBC driver's SSL certificate validation contains a critical security vulnerability that allows hostname spoofing attacks. The current parseCommonName() method uses unsafe string parsing on the "canonical" format of X.509 Distinguished Names, which can be exploited by malicious certificates.
Security Impact
An attacker can craft malicious X.509 certificates that bypass hostname validation by embedding fake hostnames within other certificate attributes. This allows man-in-the-middle attacks where:
Attacker presents a certificate with DN like: OU=CN=legitimate-server.com, CN=attacker.com
The vulnerable parser incorrectly extracts legitimate-server.com instead of the actual CN attacker.com
Application accepts the certificate as valid for legitimate-server.com when it's actually issued for attacker.com
SSL/TLS connection proceeds with compromised security
Root Cause Analysis
Unsafe String Parsing: Original code used indexOf("cn=") and substring operations on the "canonical" DN format
Format Ambiguities: The "canonical" format lowercases and reverses RDN order, creating parsing ambiguities
Insufficient Validation: No proper escaping/unescaping of DN components
Regex Vulnerabilities: Simple pattern matching vulnerable to DN injection attacks
Solution
Complete rewrite of CN parsing logic using secure, industry-standard approaches:
Secure DN Parsing:
Replaced custom string parsing with javax.naming.ldap.LdapName and Rdn classes
Uses RFC2253 format instead of vulnerable "canonical" format
Proper handling of escaped characters and DN structure
Security Testing:
Added testSecureCNParsing_preventsHostnameSpoofing() test case
Validates fix prevents known attack vectors
Mock certificate testing framework for edge cases