Read our latest security bulletins here.
  1. Container Networking Security Issue (CVE-2020-8558)

    [V2] Last Updated: 2020/07/09 6:30PM PDT

    CVE Identifier: CVE-2020-8558

    This is an update for this issue.

    AWS is aware of a security issue, recently disclosed by the Kubernetes community, affecting Linux container networking (CVE-2020-8558). This issue may allow containers running on the same host, or adjacent hosts (hosts running in the same LAN or layer 2 domain), to reach TCP and UDP services bound to localhost (127.0.0.1).

    All AWS security controls to maintain isolation between customers in Amazon ECS and Amazon EKS continue to work correctly. This issue presents no risk of cross-account data access. Processes within a container on one host may be able to gain unintended network access to other containers on that same host or on other hosts within the same VPC and subnet. Customer action is required, and steps for immediate mitigation are available at https://github.com/aws/containers-roadmap/issues/976. All Amazon ECS and Amazon EKS customers should update to the latest AMI.

    AWS Fargate
    AWS Fargate is not affected. No customer action is required.

    Amazon Elastic Container Service (Amazon ECS)
    Updated Amazon ECS Optimized AMIs are now available. As a general security best practice, we recommend that ECS customers update their configurations to launch new container instances from the latest AMI version.

    Customers can upgrade their AMIs by referring to the ECS documentation.

    Amazon Elastic Kubernetes Service (Amazon EKS)
    Updated Amazon EKS-Optimized AMIs are now available. As a general security best practice, we recommend that EKS customers update their configurations to launch new worker nodes from the latest AMI version.

    Customers using Managed node groups can upgrade their node groups by referring to the EKS documentation. Customers self managing worker nodes should replace existing instances with the new AMI version by referring to the EKS documentation

    [V1] Initial Publication Date: 2020/07/08 7:15PM PDT

    CVE Identifier: CVE-2020-8558

    You are viewing a previous version of this security bulletin.

    AWS is aware of a security issue, recently disclosed by the Kubernetes community, affecting Linux container networking (CVE-2020-8558). This issue may allow containers running on the same, or adjacent hosts (hosts running in the same LAN or layer 2 domain), to reach TCP and UDP services bound to localhost (127.0.0.1).

    AWS Fargate is not affected. No customer action is required.

    All AWS security controls to maintain isolation between customers in Amazon ECS and Amazon EKS continue to work correctly. This issue presents no risk of cross-account data access. Processes within a container on one host may be able to gain unintended network access to other containers on that same host or on other hosts within the same VPC and subnet. Customer action is required, and steps for immediate mitigation are available at: https://github.com/aws/containers-roadmap/issues/976

    We will be releasing updated Amazon Machine Images for both Amazon ECS and Amazon EKS, and customers should update to these AMIs as soon as they are available.

    AWS Fargate
    AWS Fargate is not affected. No customer action is required.

    Amazon Elastic Container Service (Amazon ECS)
    Amazon ECS will be releasing updated ECS Optimized AMIs including the Amazon Linux AMI, Amazon Linux 2 AMI, GPU-Optimized AMI, ARM-Optimized AMI, and Inferentia-Optimized AMI on July 9, 2020. Updating to use one of these AMIs will mitigate the issue. We will update this bulletin when updated AMIs are available.

    Amazon Elastic Kubernetes Service (Amazon EKS)
    Amazon EKS will be releasing updated EKS Optimized AMIs including the Amazon Linux 2 EKS-Optimized AMI and EKS-Optimized accelerated AMI for Kubernetes 1.14, 1.15, and 1.16 on July 9, 2020. Updating to use one of these AMIs will mitigate the issue. We will update this bulletin when updated AMIs are available.

  2. Windows CIFS Browser Protocol Heap Corruption Vulnerability

    February 18, 2011

     

    An anonymous reporter has publicly announced a previously undisclosed vulnerability affecting the BROWSER protocol on Windows systems. In addition, the reporter has released proof-of-concept exploit code. Use of the code can result in a denial-of-service condition on the target host, and the reporter has speculated that remote code execution is also possible.

    Microsoft indicates that all versions of Windows are vulnerable. The vulnerability affects hosts that are or could become the Master Browser on the local network, such as the Primary Domain Controller. You may also be at risk if your hosts have Windows file shares exposed to the Internet.

    Microsoft is working on a fix, but at this time it is not yet available. For at-risk systems, the vulnerability can be mitigated by restricting access to UDP ports 137, 138 and TCP ports 139, 445 to only those hosts that require it. This needs to be done carefully, as the ability to use these ports is critical to many applications.

    These access restrictions can be achieved by configuring your EC2 Security Groups accordingly. For information and examples on how to properly configure your Security Groups, please refer to the following documentation:
    http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/index.html?adding-security-group-rules.html

     

  3. Minimum Version of TLS 1.2 Required for FIPS Endpoints by March 31, 2021

    Initial Publication Date: 2020/03/31 11:15AM PDT

    AWS is updating all AWS Federal Information Processing Standard (FIPS) endpoints to a minimum Transport Layer Security (TLS) version of 1.2 across all AWS Regions by March 31, 2021. This update will revoke the ability to use TLS 1.0 and TLS 1.1 on all FIPS endpoints. No other AWS endpoints will be affected by this change.

    When connecting to an AWS service endpoint, your client provides its TLS minimum and TLS maximum version. The AWS service endpoint selects the maximum version offered.

    What do I need to do?
     
    Confirm that all of your client applications support TLS 1.2, ensuring it is encapsulated between the minimum and the maximum versions. We encourage you to act now to avoid any impact to your availability and to protect the integrity of your data in transit. Additionally, we recommend that you perform these steps in a test or staging environment before completing these steps in a production environment.
     
    If you are using an AWS Software Development Kit (AWS SDK), you can find information about how to properly configure your client's minimum and maximum TLS versions on the following topics in the AWS SDK documentation:
     
    When are these changes occurring?
     
    To minimize the impact to our customers who use TLS 1.0 and TLS 1.1, we are rolling out the changes on a service-by-service basis between now and the end of March 2021.
     
    We will detect and validate customer connections to AWS FIPS endpoints. After a 30-day period during which no connections are detected, we will deploy a configuration change to remove support for them. After March 31, 2021, we may update the endpoint configuration to remove TLS 1.0 and 1.1, even if we detect customer connections. We will provide additional updates and reminders on the AWS Security Blog, with a ‘ TLS’ tag.
     
    What are AWS FIPS endpoints?
     
    All AWS services offer Transport Layer Security (TLS) 1.2 encrypted endpoints that can be used for all API calls. Some AWS services also offer FIPS 140-2 endpoints for customers that require use of FIPS validated cryptographic libraries.
     
    What is Transport Layer Security (TLS)?
     
    Transport Layer Security (TLS) is a cryptographic protocol designed to provide secure communication across a computer network. API calls to AWS services are secured using TLS.
     
    How can I get additional assistance to verify or update my client application?
     
    If you have any questions or issues, please contact AWS Support or your Technical Account Manager (TAM). The AWS Technical Support tiers cover development and production issues for AWS products and services, along with other key stack components. AWS Support does not include code development for client applications.
     
    Customers also may use AWS IQ to find and securely work with AWS Certified third-party experts for on-demand project work. Visit the AWS IQ page for information about how you can submit your request, get responses from experts, and choose the expert with the skills and experience you require. You can log into your console and select Get Started with AWS IQ to start your request.
  4. Kubernetes Security Issue (CVE-2019-11249)

    Last Updated: August 15, 2019 9:00AM PDT

    CVE Identifier: CVE-2019-11249

    AWS is aware of a security issue (CVE-2019-11249) which resolves incomplete fixes for CVE-2019-1002101 and CVE-2019-11246. Like the aforementioned CVEs, the issue is in the Kubernetes kubectl tool that could allow a malicious container to replace or create files on a user's workstation.

    If a user were to run an untrusted container containing a malicious version of the tar command and execute the kubectl cp operation, the kubectl binary unpacking the tar file could overwrite or create files on a user's workstation.

    AWS customers should refrain from using untrusted containers. If customers use an untrusted container and use the kubectl tool to manage their Kubernetes clusters, they should refrain from running the kubectl cp command using the affected versions and update to the latest kubectl version.

    Updating Kubectl

    Amazon Elastic Kubernetes Service (EKS) currently vends kubectl for customers to download from the EKS service S3 bucket. Download and install instructions can be found in the EKS Userguide. Customers can run the command "kubectl version --client" to discover which version they are using.

    For a list of affected kubectl versions, and the recommended versions to which we recommend updating, please refer to the table below:

    EKS-optimized AMIs

    The EKS-optimized AMIs for Kubernetes at version v20190701 no longer contain kubectl. Customers running v20190701 or newer are not impacted, and no action is required. Customers running a previous version of the EKS AMI should update to the latest EKS AMI.

    CVE-2019-11246 was addressed in AWS-2019-006.

  5. Kubernetes Security Issue (CVE-2019-11246)

    July 02, 2019 2:00 PM PDT

    CVE Identifier: CVE-2019-11246

    AWS is aware of a security issue (CVE-2019-11246) in the Kubernetes kubectl tool that could allow a malicious container to replace or create files on a user's workstation.

    If a user were to run an untrusted container containing a malicious version of the tar command and execute the kubectl cp operation, the kubectl binary unpacking the tar file could overwrite or create files on a user's workstation.

    AWS customers should refrain from using untrusted containers. If customers use an untrusted container and use the kubectl tool to manage their Kubernetes clusters, they should refrain from running the kubectl cp command using the affected versions and update to the latest kubectl version.

    Updating Kubectl
    AWS currently vends kubectl for customers to download in the EKS service S3 bucket, as well as shipping the binary in our managed AMI.

    1.10.x: Versions of kubectl vended by AWS 1.10.13 or earlier are affected. We recommend that you update to kubectl version 1.11.10.

    1.11.x: Versions of kubectl vended by AWS 1.11.9 or earlier are affected. We recommend that you update to kubectl version 1.11.10..

    1.12.x: Versions of kubectl vended by AWS 1.12.7 or earlier are affected. We recommend that you update to kubectl version 1.12.9.

    1.13.x: kubectl 1.13.7 vended by AWS is not impacted.

    EKS-optimized AMIs
    The EKS-optimized AMIs for Kubernetes versions 1.10.13, 1.11.9, and 1.12.7 currently contain affected versions of kubectl.

    New versions of the EKS-optimized AMIs will be released today and will no longer include the kubectl binary. EKS AMI does not rely on kubectl binary and it was previously provided as a convenience. Customers relying on kubectl being present in the AMI will need to install it themselves when upgrading to the new AMI. In the meantime, users should update the kubectl version manually on any running instantiation of the AMI before using it.