Latest Bulletins

Issue with NVIDIA Container Toolkit (CVE-2024-0132, CVE-2024-0133)

Wed, 02 Oct 2024 01:46:51 +0000

Publication Date: 2024/10/01 6:35 PM PDT

AWS is aware of CVE-2024-0132 and CVE-2024-0133, issues affecting the NVIDIA container toolkit 1.16. At this time, the following services require customer action. If we become aware of additional impact, we will update this bulletin.

Amazon Elastic Container Service (Amazon ECS)

Amazon ECS has released updated ECS GPU-optimized Amazon Machine Images (AMIs) with the patched NVIDIA container toolkit v1.16.2. We recommend that ECS customers update to these AMIs (or the latest available). Additional information on the ECS-optimized AMI is available at in our "Amazon ECS-optimized Linux AMIs" developer guide.

Amazon Elastic Kubernetes Service (Amazon EKS)

Amazon EKS has released updated EKS GPU-optimized Amazon Machine Images (AMIs) version v20240928 with the patched NVIDIA container toolkit v1.16.2. Customers using Managed node groups can upgrade their node groups by referring to the EKS documentation. Customers using Karpenter can update their nodes by following the documentation on drift or AMI selection. Customers using self-managing worker nodes can replace existing nodes by referring to the EKS documentation.

Bottlerocket

Amazon has released Bottlerocket 1.24.0, which includes the patched NVIDIA container toolkit v1.16.2, and recommend customers using Bottlerocket apply this update or a newer version. Further information will be posted in the Bottlerocket Security Advisories and the Bottlerocket Release Notes.

If you have any questions or comments about this advisory, we ask that you contact AWS/Amazon Security via our vulnerability reporting page or directly via email to [email protected]">[email protected].

Issue with DynamoDB local - CVE-2022-1471

Wed, 11 Dec 2024 23:59:42 +0000

Publication Date: 2024/12/11 2:00PM PST

AWS is aware of CVE-2022-1471 in SnakeYaml software, included in DynamoDB local jar and Docker distributions from version 1.21 and version 2.0. If leveraged, this issue could allow an actor to perform remote code execution using the SnakeYaml's Constructor(), as the software does not restrict the types that can be instantiated during deserialization. AWS has found no evidence that this issue has been leveraged, however, customers should still take action. On November 6, 2024, we released a fix for this issue. Customers should upgrade DynamoDB local to the latest version: v1.25.1 and above, or 2.5.3 and above.

Please email [email protected]">[email protected] with any security questions or concerns.

Issue with data.all (Multiple CVEs)

Sat, 09 Nov 2024 01:16:14 +0000

Publication Date: 2024/11/8 4:00 PM PDT

Data.all is an open source development framework to help customers build a data marketplace on AWS.

We have identified the following issues within data.all version 1.0.0 through 2.6.0. On November 8, 2024, we released a fix and recommend customers upgrade to version 2.6.1 or later and ensure any forked or derivative code are patched to incorporate the new fixes.

CVE-2024-52311 relates to an issue where data.all does not invalidate authentication token upon user logout.
CVE-2024-52312 relates to an issue where data.all authenticated users can perform restricted operations against DataSets and Environments.
CVE-2024-52313 relates to an issue where data.all authenticated users can obtain incorrect object level authorizations.
CVE-2024-52314 relates to an issue where data.all admin user may access potentially sensitive data stored by producers via logs.
CVE-2024-10953 relates to an issue where data.all authenticated users can perform mutating update operations on persisted notification records.

References:

CVE-2024-52311 GitHub Security Advisory
CVE-2024-52312 GitHub Security Advisory
CVE-2024-52313 GitHub Security Advisory
CVE-2024-52314 GitHub Security Advisory
CVE-2024-10953 GitHub Security Advisory

Please email [email protected]">[email protected] with any security questions or concerns.

CVE-2024-10125 - missing JWT issuer and signer validation in aws-alb-identity-aspnetcore

Mon, 21 Oct 2024 23:01:38 +0000

Publication Date: 2024/10/21 4:00 PM PDT

Description:

The Amazon.ApplicationLoadBalancer.Identity.AspNetCore repo contains Middleware that can be used in conjunction with the Application Load Balancer (ALB) OpenId Connect integration and can be used in any ASP.NET Core deployment scenario, including AWS Fargate, Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Compute Cloud (Amazon EC2), and AWS Lambda. In the JWT handling code, it performs signature validation but fails to validate the JWT issuer and signer identity. The signer omission, if combined with a scenario where the infrastructure owner allows internet traffic to the ALB targets (not a recommended configuration), can allow for JWT signing by an untrusted entity and an actor may be able to mimic valid OIDC-federated sessions to the ALB targets.

Affected versions: all versions

Resolution

The repository/package has been deprecated, is End of Life, and is no longer actively supported.

Workarounds

As a security best practice, ensure that your ELB targets (e.g. EC2 Instances, Fargate Tasks etc.) do not have public IP addresses.

Ensure any forked or derivative code validate that the signer attribute in the JWT match the ARN of the Application Load Balancer that the service is configured to use.

References

ALB Documentation specifically "To ensure security, you must verify the signature before doing any authorization based on the claims and validate that the signer field in the JWT header contains the expected Application Load Balancer ARN."
Python example
GitHub Security Advisory
CVE-2024-10125

We would like to thank Miggo Security for collaborating on this issue through the coordinated disclosure process.

Please email [email protected]">[email protected] with any security questions or concerns.

CVE-2024-8901 - missing JWT issuer and signer validation in aws-alb-route-directive-adapter-for-istio

Mon, 21 Oct 2024 23:48:35 +0000

Publication Date: 2024/10/21 4:00 PM PDT

The AWS ALB Route Directive Adapter For Istio repo provides an OIDC authentication mechanism that was integrated into the open source Kubeflow project. The adapter uses JWT for authentication, but lacks proper signer and issuer validation. In deployments of ALB that ignore security best practices, where ALB targets are directly exposed to internet traffic, an actor can provide a JWT signed by an untrusted entity in order to spoof OIDC-federated sessions and successfully bypass authentication.

Affected versions: v1.0, v1.1

Resolution

The repository/package has been deprecated, is End of Life, and is no longer actively supported.

Workarounds

As a security best practice, ensure that your ELB targets (e.g. EC2 Instances, Fargate Tasks etc.) do not have public IP addresses.

Ensure any forked or derivative code validate that the signer attribute in the JWT match the ARN of the Application Load Balancer that the service is configured to use.

References

ALB Documentation specifically "To ensure security, you must verify the signature before doing any authorization based on the claims and validate that the signer field in the JWT header contains the expected Application Load Balancer ARN."
Python example
GitHub Security Advisory
CVE-2024-8901

We would like to thank Miggo Security for collaborating on this issue through the coordinated disclosure process.

Please email [email protected]">[email protected] with any security questions or concerns.

Issue with RedShift JDBC Driver, Python Connector and ODBC Driver - (CVE-2024-12744, CVE-2024-12745, CVE-2024-12746)

Tue, 24 Dec 2024 18:04:59 +0000

Publication Date: 2024/12/24 10:00AM PST

AWS has identified the following issues within the Amazon Redshift JDBC Driver, Amazon Redshift Python Connector, and Amazon Redshift ODBC Driver. On December 23, 2024, we released a fix and recommend customers upgrade to the latest version to address these issues.

The Amazon Redshift JDBC Driver, version 2.1.0.31, is affected by CVE-2024-12744, a SQL injection issue when utilizing the getSchemas, getTables, or getColumns Metadata APIs. This issue has been addressed in driver version 2.1.0.32. We recommend customers upgrade to the driver version 2.1.0.32 or revert to driver version 2.1.0.30.
The Amazon Redshift Python Connector, version 2.1.4, is affected by CVE-2024-12745, a SQL injection issue when utilizing the get_schemas, get_tables, or get_columns Metadata APIs. This issue has been addressed in driver version 2.1.5. We recommend customers upgrade to the driver version 2.1.5 or revert to driver version 2.1.3.
The Amazon Redshift ODBC Driver, version v2.1.5.0 (Windows or Linux), is affected by CVE-2024-12746, a SQL injection issue when utilizing the SQLTables or SQLColumns Metadata APIs. This issue has been addressed in driver version 2.1.6.0. We recommend customers upgrade to the driver version 2.1.6.0 or revert to driver version 2.1.4.0.

Affected versions: Amazon Redshift JDBC Driver, version 2.1.0.31; Amazon Redshift Python Connector, version 2.1.4; Amazon Redshift ODBC Driver, version v2.1.5.0.

Resolution:
Users of the Amazon Redshift JDBC Driver should upgrade to the driver version 2.1.0.32 or revert to driver version 2.1.0.30.

Users of the Amazon Redshift Python Connector are recommended to upgrade to the driver version 2.1.5 or revert to driver version 2.1.3.

Users of the Amazon Redshift ODBC Driver are recommended to upgrade to the driver version 2.1.6.0 or revert to driver version 2.1.4.0.

References:

CVE-2024-12744 GitHub Security Advisory
CVE-2024-12745 GitHub Security Advisory
CVE-2024-12746 GitHub Security Advisory

Please email [email protected]">[email protected] with any security questions or concerns.

Issue with PyTorch TorchServe - CVE-2024-35198, CVE-2024-35199

Mon, 22 Jul 2024 15:47:29 +0000

Publication Date: 2024/07/18 2:50 PM PDT

AWS is aware of the issues described in CVE-2024-35198 and CVE-2024-35199 in PyTorch TorchServe versions 0.3.0 to 0.10.0. Customers using PyTorch inference Deep Learning Containers (DLC) through Amazon SageMaker are not affected.

CVE-2024-35198 does not prevent a model from being downloaded into the model store if the URL contains characters such as ".." when TorchServe model registration API is called. Customers using PyTorch inference Deep Learning Containers (DLC) through Amazon SageMaker and Amazon Elastic Kubernetes Service (Amazon EKS) are not affected by this issue.

CVE-2024-35199 does not bind two gRPC ports 7070 and 7071 to localhost by default. These two interfaces are bound to all interfaces when TorchServe is natively launched without Docker container. Customers using PyTorch inference Deep Learning Containers (DLC) are not affected by this issue.

TorchServe version v0.11.0 resolves these two issues.

Customers can use the following new image tags to pull DLCs that ship with patched TorchServe version 0.11.0. Alternatively, customers can upgrade to the latest version of TorchServe.

PyTorch 2.2

PyTorch 2.1

PyTorch 1.13

The full DLC image URI details can be found at: https://github.com/aws/deep-learning-containers/blob/master/available_images.md#available-deep-learning-containers-images.

We would like to thank Kroll Cyber Risk for collaborating on this issue through the coordinated vulnerability disclosure process.

Issue with AWS Client VPN - CVE-2024-30164, CVE-2024-30165

Mon, 22 Jul 2024 15:47:30 +0000

Publication Date: 2024/07/16 3:30 PM PDT

AWS is aware of CVE-2024-30164 and CVE-2024-30165 in AWS Client VPN. These issues could potentially allow an actor with access to an end user's device to escalate to root privilege and execute arbitrary commands on that device. We addressed these issues on all platforms. Customers using AWS Client VPN should upgrade to version 3.11.1 or higher for Windows, 3.9.2 or higher for MacOS, and 3.12.1 or higher for Linux.

For additional information on configuring AWS Client VPN to meet your security and compliance requirements, please refer to our "Security in AWS Client VPN" user guide.

We would like to thank Robinhood for collaborating on this issue through the coordinated vulnerability disclosure process.

Security-related questions or concerns can be brought to our attention via [email protected]">[email protected].

Issue With IAM Supporting Multiple MFA Devices

Tue, 25 Apr 2023 14:03:37 +0000

Initial Publication Date: 04/25/2023 10:00AM EST

A security researcher recently reported an issue with AWS’s recently-released (November 16th, 2022) support for multiple multi-factor authentication (MFA) devices for IAM user principals. The reported issue could have potentially arisen only when the following three conditions were met: (1) An IAM user had possession of long-term access key (AK)/secret key (SK) credentials, (2) that IAM user had the privilege to add an MFA to their own identity without using an MFA, and (3) that IAM user’s overall access privileges beyond console sign-in had been configured by an administrator to be greater after adding the MFA. Under those narrow conditions, possession of AK/SK alone was equivalent to possession of AK/SK and a previously configured MFA.

While IAM users with the ability to add or delete an MFA device associated with their own identity have always been able to do so solely with AK/SK credentials, an issue arose when the new feature was combined with the self-management by IAM users of their own MFA devices, with restricted access prior to an MFA being added by the user. This self-management pattern was documented here, and that page included a sample IAM policy for implementing the pattern. The combination of the new multi-MFA feature created an inconsistency with that approach. Given the new feature, a user with only AK/SK credentials could add an additional MFA without using a previously-configured MFA, thus allowing possession of AK/SK alone without a previously configured MFA to potentially gain broader access than expected by customers using the sample policy.

This issue did not affect AWS Management Console-based access, since an existing MFA is always required at sign-in. Nor did it affect federated principals, who manage MFA through their identity provider.

As of April 21, 2023, the identified issue has been remediated by requiring that IAM users who already have one or more MFAs and who use AK/SK credentials to manage their own MFA devices to first use sts:GetSessionToken and an existing MFA to obtain MFA-enabled temporary credentials to sign their CLI commands or API requests prior to enabling or disabling MFA devices for themselves. We have directly notified a very small number of customers via their Personal Health Dashboard who had previously associated an additional MFA device using a mechanism other than the AWS Management Console. We recommended that those notified customers confirm the correctness of their MFA configurations. No further customer action is required.

We would like to thank researchers at MWR Cybersec for identifying and responsibly disclosing this issue to AWS. Security-related questions or concerns can be brought to our attention via [email protected]">[email protected].

CVE-2024-28056

Tue, 16 Apr 2024 00:33:27 +0000

Publication Date: 2024/04/15 07:00 AM PST

AWS is aware of CVE-2024-28056, which affects Amplify CLI versions prior to 12.10.1 and Amplify Studio, which uses Amplify CLI. We released a fix to Amplify CLI on January 10, 2024 that also fixed Amplify Studio, and recommend customers upgrade to Amplify CLI 12.10.1 or higher to address this issue. We have proactively communicated with the customers using affected versions.

AWS has taken two additional steps to protect customers using Amplify from unintentional misconfigurations. First, AWS added a mitigation to the AWS Security Token Service (STS) where attempts to make a cross-account role assumption with a trust policy referencing Amazon Cognito as the trusted principal, without conditions to scope down access to specific Amazon Cognito Identity Pools using the aud claim, will fail. As a result, cross-account access will no longer be possible with policies created by earlier unpatched versions of Amplify. Second, AWS added a mitigation to the AWS Identity and Access Management (IAM) control plane such that any attempt to create a role trust policy that references Amazon Cognito as the trusted principal, without adding conditions restricting access, will fail.

We would like to thank Datadog for responsibly disclosing this issue to AWS.

Please email [email protected]">[email protected] with any security questions or concerns.