I work on a product that provides a JNI wrapper around a native API, we 
currently use LD_PRELOAD to enable signal chaining.  We chose LD_PRELOAD as we 
do not force our customers to a specific Java vendor or version, nor do we want 
to complicate our build process by creating a unique build for each of the 
various Java vendor/versions our customers may be using.  We've recently 
discovered that the use of LD_PRELOAD is considered a code injection risk by 
security analysis tools, such as ones that check for OWASP 2017.
Is there anything we may not be considering to allow our JNI dependent product 
to be OWASP compliant? Or does anyone know if there are plans to address this 
in a new or alternate way in the future to allow a JNI application to be OWASP 
compliant?  Builds linking against each supported JVM would work, but going 
from 1 to 9 builds (roughly 3 JDK vendors x 3 active JDK version levels) on 5 
platforms will certainly add to our maintenance and testing cycles.

Reply via email to