Open alex-rowe opened 2 months ago
We found the same here, tested on 2.17.12 on ARM.
strings aws-cli/2.17.12/dist/libcrypto.so.1.1 | grep "^OpenSSL 1.1.1"
OpenSSL 1.1.1y 04 JUN 2024
strings aws-cli/2.17.12/dist/libssl.so.1.1 | grep "^OpenSSL 1.1.1"
OpenSSL 1.1.1y 04 JUN 2024
Systems are all Linux aarch64
Thanks for reporting this. The CVE referenced is low severity and the CLI should not be impacted. However the team is aware of this issue and is planning to update the OpenSSL version in the near future.
I noticed the AMD/x86_64 CLI doesn't have these files available so they don't get picked up by the scanners. Is the ARM/aarch64 CLI build different that it still needs to have these files left over or can they be removed?
@tim-finnigan The CVE is a 9.1 Critical score on CVSS v3 which changes our SLOs for fixing these kinds of reported vulnerabilities.
Based on by above comment, can the ARM distributions be made the same as the AMD versions where it's not bundled and available under /aws/dist/
?
Per OpenSSL (see: https://www.openssl.org/news/vulnerabilities-3.1.html#y2024) regarding the CVE:
This issue has been assessed as Low severity because applications are most likely to be vulnerable if they are using NPN instead of ALPN - but NPN is not widely used. It also requires an application configuration or programming error. Finally, this issue would not typically be under attacker control making active exploitation unlikely.
Regarding the distributions: the x86_64 installer is statically linked and contains the same code as the arm64 installer, but the code is not packaged in a separate .so file. The arm64 installer is dynamically linked and uses system libraries, but also includes libcrypto.so in case it's missing. If one is flagged and the other isn't then the issue may be with the auditing tool, not the installers, since both have the same threat model.
Thanks @tim-finnigan I'll see about getting the CVE reassessed on our end to also move it to low.
If we're using an OS (Ubuntu) which does comes with the libraries dynamically linked to system libraries, can the files be removed from /usr/local/aws-cli/v2/{version}/dist
?
The scanner/auditing tool in this case is simply looking for a file called libcrypto.so...
and if it exists, check the version. The x86_64 installer/zip doesn't come with the libcrypto/libssl
.so
files so they don't get picked up by the scanner.
Checking the linked binaries for AWS on arm64, we get
lddtree /usr/local/aws-cli/v2/2.17.11/dist/aws
aws => /usr/local/aws-cli/v2/2.17.11/dist/aws (interpreter => /lib/ld-linux-aarch64.so.1)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2
ld-linux-aarch64.so.1 => /lib/ld-linux-aarch64.so.1
libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6
I can't see SSL/crypto mentioned there to use a system library.
Checking strace
it seems we are using the provided files on ARM
# strace -fo strace.log aws sts get-caller-identity
# grep "libcrypto\|libssl" strace.log
1292806 openat(AT_FDCWD, "/usr/local/aws-cli/v2/2.17.11/dist/libcrypto.so.1.1", O_RDONLY|O_CLOEXEC) = 3
1292806 openat(AT_FDCWD, "/usr/local/aws-cli/v2/2.17.11/dist/libssl.so.1.1", O_RDONLY|O_CLOEXEC) = 3
When running strace
on x86_64, there's no mention of libcrypto
or libssl
.
Are there any plans for the ARM releases to also be statically linked, so they don't require the extra libraries libcrypto
etc to be packaged along with them?
Are there any plans for the ARM releases to also be statically linked, so they don't require the extra libraries
libcrypto
etc to be packaged along with them?
There are not currently plans for the ARM releases to also be statically linked, but this is something the team will need to investigate further prior to considering.
Describe the issue
Similar to https://github.com/aws/aws-cli/issues/8485
Tenable is reporting on ARM instances with AWS CLI installed, that the following files out out of date and should be updated to the latest
1.1.1za
OpenSSL releaseAWS CLI was recently updated to use the
1.1.1y
but that is also now considered out of date with the newza
release.Additional Information/Context
Tested on latest
2.17.10
Reported in https://www.tenable.com/plugins/nessus/201084
CLI version used
2.17.10
Environment details (OS name and version, etc.)
Linux aarch64