You are viewing a previous version of this security bulletin. For the most current version please visit: "Linux Kernel TCP SACK Denial of Service Issues".
June 17, 2019 10:00AM PDT
CVE Identifiers: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479
AWS is aware of three recently-disclosed issues which affect the TCP processing subsystem of the Linux kernel. Specifically, a malicious TCP client or server can transmit a specially crafted series of packets that may cause the Linux kernel of any targeted connecting system to panic and reboot.
AWS’s underlying systems and infrastructure are protected against these issues. With the exception of the AWS services listed below, no customer action is required to mitigate any potential denial-of-service (DoS) concerns related to these issues.
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.
Amazon Linux AMI and Amazon Linux 2 AMI
Updated Amazon Linux AMIs will be available shortly. We will update this bulletin when they are available for use.
Updated kernels for Amazon Linux AMI and Amazon Linux 2 are immediately available within the Amazon Linux repositories. 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.
More information will be available shortly at the Amazon Linux Security Center.
Elastic Load Balancing (ELB)
Network Load Balancers (NLBs) do not filter traffic. Linux-based EC2 instances using NLBs 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 and Application Load Balancers 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.