On Thu, Apr 11, 2019 at 08:45:51PM +0000, Hank Edwards wrote: > 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.
I would raise the issue with the vendors of the security analysis tools. Code injection is a legitimate tool for integration. > 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. Any mechanism for code injection can cause false positives in security analysis tools, therefore changing how you inject code risks being nothing more than a waste of time and effort. Nico --
