Potential secutiry vulnerabilities in the shared library which APE depends on. Can you help upgrade to patch versions?

[HelenParr]

Hi, @vedran-kasalica , @KoenHav , I'd like to report a vulnerability issue in io.github.sanctuuary:APE:1.1.12.

Issue Description

io.github.sanctuuary:APE:1.1.12 directly depends on 1 C library(.so). However, I noticed that the C library is vulnerable, containing the following CVEs:

libj2v8_linux_x86_64.so from C project openssl(version:1.0.2g) exposed 10 vulnerabilities:
CVE-2021-3712, CVE-2020-1968, CVE-2016-8610, CVE-2016-2182, CVE-2016-2181, CVE-2016-2179, CVE-2016-6302, CVE-2016-6303, CVE-2017-3738, CVE-2019-1552

Furthermore, the vulnerable methods in these vulnerable shared libraries can be actually invoked by Java code.
For instance, the following call chain starting from SSL_CTX_load_verify_locations() can reach the vulnerable method EC_GROUP_new_from_ecparameters() <EC_GROUP *EC_GROUP_new_from_ecparameters (const ECPARAMETERS *params) in crypto/ec/ec_asn1.c reported by CVE-2021-3712:

call chain -----
SSL_CTX_load_verify_locations() -> X509_STORE_load_locations() -> X509_STORE_add_lookup() -> STACK_OF() -> PEM_X509_INFO_read_bio() -> d2i_ECPrivateKey() -> EC_GROUP_new_from_ecpkparameters() -> EC_GROUP_new_from_ecparameters()

Suggested Vulnerability Patch Versions

openssl has fixed the vulnerabilities in versions >=1.1.1l

Java build tools cannot report vulnerable C libraries, which may induce potential security issues to many downstream Java projects.
Could you please upgrade the above shared libraries to their patch versions?

Thanks for your help~
Best regards,
Helen Parr

[vedran-kasalica]

Hi @HelenParr, thank you for bringing this to our attention. Unfortunately, as it is not a direct dependency, it is not trivial for us to identify the problem.
Could you please share with us some information on how to identify and track the C libraries in question?