CVE-2022-46337
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Apache Derby, in versions prior to 10.17.1.0, contains a critical security flaw where specifically crafted usernames can be used to bypass LDAP authentication checks entirely. When a Derby installation is configured to use LDAP for user authentication, it fails to properly sanitize or neutralize special characters within the username field before passing them to the downstream LDAP subsystem. This injection vulnerability allows an unauthenticated remote attacker to manipulate the authentication query logic, gaining unauthorized access to the database. Once the bypass is achieved, attackers can execute privileged database functions, view or corrupt sensitive data, and even perform disk exhaustion attacks by creating numerous "junk" databases. Furthermore, if the Derby service account has access to malicious files on the host system, the bypass could potentially facilitate the execution of malware.
Details
Module Info
- Product: Derby
- Affected packages:
org.apache.derby:derby - Affected versions: >= 10.1.1.0, < 10.14.3, >= 10.15.0.0, < 10.15.2.1, >= 10.16.0.0, < 10.16.1.2, >= 10.17.0.0, < 10.17.1.0
- SVN repository: https://svn.apache.org/repos/asf/db/derby/code/tags/10.14.2.0/
- Published packages: https://central.sonatype.com/artifact/org.apache.derby/derby
- Package manager: Maven
- Fixed In: NES for Derby v10.14.3
Vulnerability Info
A cleverly devised username might bypass LDAP authentication checks. In LDAP-authenticated Derby installations, this could let an attacker fill up the disk by creating junk Derby databases. In LDAP-authenticated Derby installations, this could also allow the attacker to execute malware which was visible to and executable by the account which booted the Derby server. In LDAP-protected databases which weren't also protected by SQL GRANT/REVOKE authorization, this vulnerability could also let an attacker view and corrupt sensitive data and run sensitive database functions and procedures.
Steps to Reproduce
- Use an application or database server running a vulnerable version of Apache Derby (e.g., 10.16.1.1) with LDAP authentication enabled and no secondary SQL authorization.
- Identify the network-accessible Derby listener and ensure that the system is configured to delegate authentication to an external LDAP directory.
- Submit a connection request using a "cleverly devised" username containing LDAP meta-characters (such as *, (, or )) designed to alter the logic of the authentication filter.
- Observe successful database access without providing valid credentials, indicating that the LDAP authentication check was bypassed.
Mitigation:
Only recent versions of Apache Derby receive community support and updates. Older versions have no publicly available fixes for this vulnerability.
Users of the affected components should apply one of the following mitigations:
Upgrade to upgrade to Java 21 and Derby 10.17.1.0
Alternatively, enable SQL Authorization (GRANT/REVOKE) in addition to LDAP authentication to ensure that even if an authentication bypass occurs, the attacker is restricted by fine-grained database permissions.
Alternatively, restrict Network Access to the Derby server ports (default 1527) to only trusted application servers or administrative IPs, reducing the exposure of the LDAP authentication path to external attackers.
Leverage a commercial support partner like HeroDevs for post-EOL security support.