RFR: 8300491: SymbolLookup::libraryLookup accepts strings with terminators [v2]

Paul Sandoz psandoz at openjdk.org
Wed May 24 20:29:58 UTC 2023


On Wed, 24 May 2023 17:09:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> There is a difference in behavior between `System::loadLibrary` and `SymbolLookup::libraryLookup(String)`. While the former catches library names containing NULL chars (because, internally it uses Path/File logic, which reject those), `SymbolLookup` does not. As a result, it is possible to load libraries such as `libGL.so\0foobar`, because the string is passed directly to `dlopen`.
>> 
>> A similar issue arises when we consider `SymbolLookup::find`, as the name is again sent unmodified to `dlopen`. In reality, some filtering *does* happen in that case, as the native code calls `GetStringUTFChars`:
>> 
>> https://docs.oracle.com/en/java/javase/20/docs/specs/jni/functions.html#getstringutfchars
>> 
>> Which encodes the NULL chars in a different form:
>> 
>> https://docs.oracle.com/en/java/javase/20/docs/specs/jni/types.html#modified-utf-8-strings
>> 
>> So, in practice, even if the input is not validated, a call to `find` with one or more NULL chars is unlikely to succeed.
>> 
>> In this patch I have added several checks to make sure that:
>> * the name of library passed to `libraryLookup(String)` does not contain `\0` and, if so, throw `IllegalArgumentException` (which is already covered by current spec;
>> * the name of a symbol passed to `SymbolLookup::find` does not contain `\0` and, if so, return empty optional. This required changes on all the lookups we implement.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test for system lookup

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14126#pullrequestreview-1442698703


More information about the core-libs-dev mailing list