OpenSSL 1.1.1y out of date in ARM distributions

alex-rowe commented 2 months ago

Describe the issue

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 commented 1 month 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

tim-finnigan commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 2 weeks ago

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.

aws / aws-cli