PBacklund949413 (Community Member) asked a question.
A hardwired library name is not acceptable to Veracode (I understand how replacing a DLL in the path would work as an attack etc), but does anyone have a good approach that is accepted?
Hi @PBacklund949413 (Community Member) ,
Veracode Static Analysis reports a flaw of CWE-114: Process Control if loadLibrary is uses as the complex path selection may be used by attackers to place their own library in a more preferred location causing the application to run attacker code.
We recommend using System.load ( https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#load(java.lang.String) ) with the full path of the library, Veracode Static Analysis will automatically detect this and close the flaw.
Thank you,
Boy Baukema
Ok, I see. In many cases (ours at least), it is not possible or wise to hardwire a particular path in a call to System.load(), but the path must be passed to the application or library though some means such as command line parameter, system property, environment variable, configuration file, classpath resource, Windows registry and so on. Each of these options in turn open different possibilities to an attacker to affect what file is being loaded.
Does Veracode place any restrictions on how the path argument to System.load() is constructed?
Hi @PBacklund949413 (Community Member) ,
Oddly Veracode Static Analysis does not currently appear to report flaws on use of System.load with data from outside of the application. I've relayed this to Veracode Research for review.
I would recommend reviewing if you are able to use one or multiple hardcoded paths. If this is not possible and the library you intend to load must be configurable then future versions of Veracode Static Analysis may report a flaw on use of this configuration. In general Veracode Static Analysis in unable to discern what data from outside the application is administrator controlled and is unable to verify that it is correctly configured. However, depending on the required functionality this may be perfectly acceptable. You can document this using a mitigation proposal ( https://help.veracode.com/go/improve_mitigation ) this must then be manually reviewed by a reviewer in your organization (typically your security team).
Thank you,
Boy Baukema
Ah, my apologies, I was mistaken. We do report System.load if data originates from outside of the application.
Thank you,
Boy Baukema
Hi Boy,
I have an issue in my code CWE:114-ProcessControl where System.loadLibrary(*dll file); is used. Can you please guide what is alternative for this to overcome this flaw.
Hi @HSivarapu495350 (Community Member) ,
We would recommend something like:
System.load("/full/path/to/filename.dll");
Thank you,
Boy Baukema
Hi Boy,
By using System.load("/full/path/to/filename.dll"); it says "java.lang.UnsatisfiedLinkError: Expecting an absolute path of the library:"
So, I tried something like this below and however no luck, still Veracode identifies it as a flaw.
static {
if (isWindowsPlatform()) {
Path pathf1 = Paths.get("lib/file1.dll").toAbsolutePath();
Path pathf2 = Paths.get("lib/file2.dll").toAbsolutePath();
String arch = System.getProperty("os.arch");
if (arch.equalsIgnoreCase("x86")) {
System.load(pathf1.toString());
}else {
System.load(pathf2.toString());
}
}
Hi Boy,
The way above with absolute path worked fine, looks some cookies issue in last scan it was still showing flaw. Now I had rescanned and the same fix worked fine. Thanks for your support!
.png){kind=logo}
Hi @PBacklund949413 (Community Member) ,
Veracode Static Analysis reports a flaw of CWE-114: Process Control if loadLibrary is uses as the complex path selection may be used by attackers to place their own library in a more preferred location causing the application to run attacker code.
We recommend using System.load ( https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#load(java.lang.String) ) with the full path of the library, Veracode Static Analysis will automatically detect this and close the flaw.
Thank you,
Boy Baukema