OpenSSL 1.1.1y out of date in ARM distributions

[alex-rowe]

Describe the issue

Similar to #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 release

  Path             : /usr/local/aws-cli/v2/2.15.50/dist/libcrypto.so.1.1
  Reported version : 1.1.1x
  Fixed version    : 1.1.1za


  Path             : /usr/local/aws-cli/v2/2.15.50/dist/libssl.so.1.1
  Reported version : 1.1.1x
  Fixed version    : 1.1.1za

AWS CLI was recently updated to use the 1.1.1y but that is also now considered out of date with the new za release.

Additional Information/Context

Tested on latest 2.17.10

% curl "https://awscli.amazonaws.com/awscli-exe-linux-aarch64.zip" -o "awscliv2.zip"
% unzip awscliv2.zip
% strings aws/dist/libcrypto.so.1.1 | grep "^OpenSSL 1.1.1" 
OpenSSL 1.1.1y  04 JUN 2024
% strings aws/dist/libssl.so.1.1 | grep "^OpenSSL 1.1.1" 
OpenSSL 1.1.1y  04 JUN 2024

Reported in https://www.tenable.com/plugins/nessus/201084

CLI version used

2.17.10

Environment details (OS name and version, etc.)

Linux aarch64

[awilmo8]

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

[tim-finnigan]

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.

[alex-rowe]

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?

[alex-rowe]

@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/?

[tim-finnigan]

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.

[alex-rowe]

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.

[alex-rowe]

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.

[alex-rowe]

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?

[tim-finnigan]

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.

[tim-finnigan]

Closing this issue as 1.1.1za is now bundled for Linux installers since version 2.17.56 per the CHANGELOG. As previously mentioned, there are not currently plans for the ARM releases to also be statically linked.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.