implicaciones de seguridad de System.load vs System.loadLibrary de Java

System.loadLibrary() se niega a cargar "bibliotecas" con el separador de ruta que aparece en el nombre; vea este extracto del código fuente de Java (en java.lang.Runtime.java ):

synchronized void loadLibrary0(Class fromClass, String libname) {
    SecurityManager security = System.getSecurityManager();
    if (security != null) {
        security.checkLink(libname);
    }
    if (libname.indexOf((int)File.separatorChar) != -1) {
        throw new UnsatisfiedLinkError(
"Directory separator should not appear in library name: " + libname);
    }
    ClassLoader.loadLibrary(fromClass, libname, false);
}

Como tal, podrías imaginarte permitir System.loadLibrary() pero rechazar System.load() , dando acceso solo a un conjunto específico de bibliotecas "seguras" que se pueden cargar ... sin embargo, esto parece indirecto y frágil. La forma "normal" de restringir la carga de código nativo es a través de SystemManager.checkLink () , que se llama desde System.load() y System.loadLibrary() . En ese caso, no hay una diferencia real en la seguridad entre los dos métodos.

Confiar en el sistema de llamadas para ayudar a ubicar las cosas sin duda puede conducir por caminos extraños. El mayor problema es que el sistema puede proporcionar un archivo que no fue diseñado para ser cargado por la aplicación. Si un atacante puede colocar un archivo en una ubicación que cae bajo la búsqueda, entonces el atacante puede inyectar un código arbitrario en la aplicación y ejecutarlo. P.ej. una vulnerabilidad de ejecución de código arbitrario ( enlace ).

Si especifica la ruta exacta, tiene la capacidad de proteger el archivo cargado a través de cosas como permisos de archivos, etc.