Forum Stats

  • 3,837,110 Users
  • 2,262,228 Discussions
  • 7,900,205 Comments

Discussions

JNI Singal Chaining and OWASP (Security)

user7726063
user7726063 Member Posts: 2
edited Apr 15, 2019 2:21PM in Java Native Interface (JNI)

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.

Best Answer

  • user7726063
    user7726063 Member Posts: 2
    edited Apr 15, 2019 2:21PM Answer ✓

    Discovered a working solution based on a suggestion from the OpenJDK community.  A user suggested they did similar by using the .init method of their shared library to load libjsig.so.  We tried something similar - adding a System.loadlibrary("jsig"); prior to loading our own native JNI library.  This gave the desired affect with all JVMs on all platforms tested.  In testing we forced exception scenarios and the program was able to recover and complete successfully.

Answers

  • user7726063
    user7726063 Member Posts: 2
    edited Apr 15, 2019 2:21PM Answer ✓

    Discovered a working solution based on a suggestion from the OpenJDK community.  A user suggested they did similar by using the .init method of their shared library to load libjsig.so.  We tried something similar - adding a System.loadlibrary("jsig"); prior to loading our own native JNI library.  This gave the desired affect with all JVMs on all platforms tested.  In testing we forced exception scenarios and the program was able to recover and complete successfully.