We provide our data scientists with ec2 instances that have statistical analysis software on them, including r-studio. These ec2s use Amazon Linux 2. We have recently been flagged for instances that we administrate that contain versions of openssl that are vulnerable to CVE-2022-1292, and the application (tenable) flags specific r-paths like this:
This path is showing the installed path of the R openssl package, and we've so far been unable to conclusively prove if this library is part of the system installed openssl package, or if the openssl R package is installing its own openssl dependency. If I load the package in R studio and then run sessionInfo(), I'm given the following version: OpenSSL 1.0.2k-fips 26 Jan 2017 (FIPS) - this matches the installed system version, which we know to be patch for the vulnerability, but since the .so library is not being 'managed' by our system, it's flagged as vulnerable.
For contrast, here is a (not vulnerable path): /usr/local/ssl/bin/openssl, which provides the same version: OpenSSL 1.0.2k-fips 26 Jan 2017 (FIPS). The key difference is that I can run the following to definitively point to a patched version:
Whereas if I run the above command on the R provided path, I don't get any helpful output
> rpm -qf /opt/R/3.6.3/lib/R/library/openssl/libs/openssl.so
file /opt/R/3.6.3/lib/R/library/openssl/libs/openssl.so is not owned by any package
The reason I was hoping to get some insight into how R/Rstudio manages system dependencies like this, and whether or not there's a way to show if they're using the underlying system package or providing their own bundled version of the openssl library.
I think the answer you are looking for depends on how R gets onto the AMI that you are supporting. This StackOverflow answer implies that there are two versions of R on linux, and if you choose the r-cran-openssl version, OpenSSL will get installed/is compiled as part of the R binary.
The openssl R package is built against the OpenSSL RPM that the linux distribution (e.g. Amazon Linux 2 in your case provides). You can check that by running ldd /opt/R/3.6.3/lib/R/library/openssl/libs/openssl.so in a terminal and you will get an output similar to (ldd is listing all the dynamically loaded libraries that a certain file is linked against).
The two most important lines are the ones containing libssl.so.10 and libcrypto.so.10 which you both can trace back to the OpenSSL installation provided by the linux distribution (e.g. via rpm -qfi /lib64/libssl.so.10).
I guess if you show your IT security team the above combination of ldd and rpm -qfi you should be able to convince them that the openssl R package is using the patched version of the openssl linux software. Finally, as a proof that the installed openssl software is the patched one, get the first few lines of the changelog via rpm -q openssl-libs --changelog | head -2 which will lead to
# rpm -q openssl-libs --changelog | head -2
* Mon Jan 29 2024 Keerthana Purushotham <keepur@amazon.com> - 1.0.2k-24.amzn2.0.12
- Fix for CVE-2024-0727