Last Updated: June 17, 2019 17:00PM PDT
CVE Identifiers: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479
This is an update for this issue.
AWS Elastic Beanstalk
Updated AWS Elastic Beanstalk Linux-based 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 Linux and Amazon Linux 2
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.
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.