Read our latest security bulletins here.
  1. 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

     

  2. 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.
  3. 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.

  4. 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. 

  5. [v2] Linux Kernel TCP SACK Denial of Service Issues

    Last Updated: June 17, 2019 14:15PM PDT

    CVE Identifiers: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

    This is an update for this issue.

    Updated Linux kernels for Amazon Linux are available in the Amazon Linux repositories, and updated Amazon Linux AMIs are available for use. Customers with existing EC2 instances running Amazon Linux should run the following command within each EC2 instance running Amazon Linux to ensure they receive the updated package:

    sudo yum update kernel

    As is standard for any update of the Linux kernel, after the yum update is complete, a reboot is required for updates to take effect.

    Customers not using Amazon Linux should contact their operating system vendor for any updates or instructions necessary to mitigate any potential DoS concerns of these issues. More information is available at the Amazon Linux Security Center.

    Amazon Elastic Compute Cloud (EC2)

    Customer EC2 Linux-based instances either initiating or directly receiving TCP connections to or from untrusted parties, e.g. the Internet, require operating system patches to mitigate any potential DoS concerns of these issues. NOTE: Customers using Amazon Elastic Load Balancing (ELB) should review "Elastic Load Balancing (ELB)" below for additional guidance.

    Elastic Load Balancing (ELB)

    TCP Network Load Balancers (NLBs) do not filter traffic, unless they are configured to terminate TLS sessions. NLBs which are configured to terminate TLS sessions do not require any additional customer action to migitate this issue.

    Linux-based EC2 instances using TCP NLBs which do not terminate TLS sessions require operating system patches to mitigate any potential DoS concerns related to these issues. Updated kernels for Amazon Linux are available now, and instructions for updating EC2 instances currently running Amazon Linux are provided above. Customers not using Amazon Linux should contact their operating system vendor for any updates or instructions necessary to mitigate any potential DoS concerns.

    Linux-based EC2 instances using Elastic Load Balancing (ELB) Classic Load Balancers, Application Load Balancers, or Network Load Balancers with TLS Termination (TLS NLB) do not require any customer action. ELB Classic and ALB will filter incoming traffic to mitigate any potential DoS concerns of these issues.

    Amazon WorkSpaces (Linux)

    All new Amazon Linux WorkSpaces will be launched with the updated kernels. The updated kernels for Amazon Linux 2 have already been installed for existing Amazon Linux WorkSpaces.

    As is standard for any update of the Linux kernel, a reboot is required for updates to take effect. We recommend that customers manually reboot as soon as possible. Otherwise, Amazon Linux WorkSpaces will reboot automatically between 12:00AM and 4:00AM local time on June 18th.

    Amazon Elastic Container Service for Kubernetes (Amazon EKS)

    All currently-running Amazon EKS clusters are protected against these issues. Amazon EKS published updated EKS-optimized Amazon Machine Images (AMIs) with the patched Amazon Linux 2 kernel on June 17, 2019. More information about the EKS-optimized AMI is available at https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html.

    We recommend that EKS customers replace all worker nodes to use the latest EKS-optimized AMI version. Instructions on updating worker nodes are available at https://docs.aws.amazon.com/eks/latest/userguide/update-workers.html.

    AWS Elastic Beanstalk

    Updated AWS Elastic Beanstalk Linux-based platforms will be available on June 17, 2019. This bulletin will be updated when the new platform versions are available. Customers using Managed Platform Updates will be automatically updated to the latest platform version in their selected maintenance window with no other action required. Alternatively, customers using Managed Platform Updates may independently apply available updates earlier than their selected maintenance window by going to the Managed Updates configuration page and clicking on the "Apply Now" button.

    Customers who have not enabled Managed Platform Updates must update their environment's platform version by following the above instructions. More information on Managed Platform Updates is available at https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environment-platform-update-managed.html

    Amazon ElastiCache

    Amazon ElastiCache launches clusters of Amazon EC2 instances running Amazon Linux into customer VPCs. These do not accept untrusted TCP connections by default and are not affected by these issues.

    Any customers who have made changes to the default ElastiCache VPC configuration should ensure their ElastiCache security groups follow AWS-recommended security best practices, by configuring them to block network traffic from untrusted clients to mitigate any potential DoS concerns. More information on ElastiCache VPC configuration is available at https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/VPCs.html.

    Customers who have their ElastiCache clusters running outside of their VPCs, and have made changes to the default configuration, should configure trusted access using ElastiCache security groups. For more information on creating ElastiCache security groups, see https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/SecurityGroups.html

    The ElastiCache team will release a new patch shortly, which addresses these issues. Once this patch is available, we will notify customers that it is ready to be applied. Customers can then choose to update their clusters with the ElastiCache self-service update feature. More information on ElastiCache self-service patch updates is available at https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/applying-updates.html.

    Amazon EMR

    Amazon EMR launches clusters of Amazon EC2 instances running Amazon Linux into customers' VPCs on their behalf. These clusters do not accept untrusted TCP connections by default, and thus are not impacted by these issues.

    Any customers who have made changes to the default EMR VPC configuration should ensure their EMR security groups follow AWS-recommended security best practices; blocking network traffic from untrusted clients to mitigate any potential DoS concerns. See https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-security-groups.html for more information on EMR security groups.

    Customers who choose not to configure EMR security groups according to AWS-recommended security best practices (or who require operating system patches to meet any additional security policy), can follow the instructions below to update new or existing EMR clusters to mitigate these issues. NOTE: These updates will require reboots of cluster instances and may impact running applications. Customers should not restart their clusters until they deem it necessary to do so:

    For new clusters, use an EMR bootstrap action to update the Linux kernel and reboot each instance. More information on EMR bootstrap actions is available at https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-bootstrap.html

    For existing clusters, update the Linux kernel on each instance within a cluster and reboot them in a rolling fashion.