CVE-2013-2035: Improper Control of Generation of Code in HawtJNI
Summary
CVE-2013-2035: Improper Control of Generation of Code in HawtJNI. Affects org.fusesource.hawtjni:hawtjni-runtime versions < 1.8. Fixed in 1.8. How to fix ↓
Also tracked for
- hawtjni · Debian:11
The same CVE-2013-2035 is tracked separately for each ecosystem and vendor. Its fix information is the same; the package and affected versions differ.
Check if this vulnerability affects your application
Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.
No signup required · Results in about 60 seconds
Background
HawtJNI is a library that provides Java Native Interface (JNI) bindings for various platforms. It allows Java applications to interact with native code and libraries. The hawtjni-runtime package is a part of HawtJNI and provides runtime support for JNI operations. This vulnerability affects versions of HawtJNI prior to 1.8. The vulnerability arises due to a race condition in the Library.java file when a custom library path is not specified. It allows local users to execute arbitrary Java code by overwriting a temporary JAR file with a predictable name in the /tmp directory.
Vulnerability Detail
The vulnerability in HawtJNI allows an attacker with local access to the system to exploit a race condition and execute arbitrary Java code. By overwriting a temporary JAR file with a predictable name in the /tmp directory, the attacker can replace the legitimate JAR file with a malicious one. When the application using HawtJNI loads the library, it inadvertently executes the attacker's code instead of the intended library code. This can lead to various consequences depending on the privileges of the user running the application, potentially resulting in unauthorized access, data manipulation, or denial of service.
How To Fix
Minimum fixed version
1.8
This is the first release that contains the fix.
Tip — Not sure which version your app runs? Vulert can match this fix to it. Scan free →
Workaround
If upgrading to the latest version of HawtJNI is not immediately feasible, a possible workaround is to specify a custom library path instead of relying on the default behavior. By explicitly setting the library path to a secure directory, the vulnerability can be mitigated. For example, you can use the following code snippet to set the library path programmatically:
System.setProperty("java.library.path", "/path/to/secure/directory");
Conclusion
The vulnerability in HawtJNI allows local users to execute arbitrary Java code by exploiting a race condition. To mitigate this vulnerability, it is recommended to upgrade to HawtJNI version 1.8 or later. If immediate upgrade is not possible, specifying a custom library path can serve as a temporary workaround. For further assistance and support in vulnerability remediation, please contact DevNack.com.
See every vulnerability recorded for org.fusesource.hawtjni:hawtjni-runtime →
FAQ
HawtJNI is a library that provides Java Native Interface (JNI) bindings for various platforms. It allows Java applications to interact with native code and libraries.
The vulnerability allows local users to execute arbitrary Java code by overwriting a temporary JAR file. Depending on the privileges of the user running the application, this can lead to unauthorized access, data manipulation, or denial of service.
To fix this vulnerability, upgrade to HawtJNI version 1.8 or later. Update the dependency in your project's pom.xml file to use the latest version of the hawtjni-runtime package.
Yes, if upgrading to the latest version is not immediately feasible, you can specify a custom library path instead of relying on the default behavior. By setting the library path to a secure directory, the vulnerability can be mitigated.
You can find more information about this vulnerability in the CVE-2013-2035 advisory and the GitHub advisory database.
