Help Center> Cloud Container Instance (CCI)> User Guide> Security Vulnerability Responses> Notice on Fixing Linux Kernel SACK Vulnerabilities
View PDF

Notice on Fixing Linux Kernel SACK Vulnerabilities

The HUAWEI CLOUD CCI team provided a solution to fix the SACK vulnerabilities in Linux kernel at 00:00 on July 11.

  • Pods that are not associated with an ELB or EIP are not affected by these vulnerabilities because they are not exposed to the public network. Therefore, no action is required.
  • Deployments that were created after 00:00 on July 11 are not affected by these vulnerabilities. However, you are advised to recreate pods in the Deployments that were created before 00:00 on July 11, during off-peak hours. For details, see Solution.
  • After existing job or cron jobs are completed, pods created by the next job or cron job will not be affected by these vulnerabilities. Therefore, no action is required.
  • The coredns add-on is not affected by these vulnerabilities. Therefore, no action is required.

Vulnerability Details

On June 18, 2019, Red Hat released a security notice, stating that the TCP SACK module of the Linux kernel is exposed to three security vulnerabilities (CVE-2019-11477, CVE-2019-11478, and CVE-2019-11479). These vulnerabilities are related to the maximum segment size (MSS) and TCP Selective Acknowledgment (SACK) packets. Remote attackers can exploit these vulnerabilities to trigger a denial of service (DoS), resulting in server unavailability or breakdown.

Reference links:

https://www.suse.com/support/kb/doc/?id=7023928

https://access.redhat.com/security/vulnerabilities/tcpsack

https://www.debian.org/lts/security/2019/dla-1823

https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SACKPanic?

https://lists.centos.org/pipermail/centos-announce/2019-June/023332.html

https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md

Table 1 Vulnerability information

Vulnerability Type

CVE-ID

Published

Fixed

Input validation flaw

CVE-2019-11477

2019-06-17

2019-07-11

Resource management flaw

CVE-2019-11478

2019-06-17

2019-07-11

Resource management flaw

CVE-2019-11479

2019-06-17

2019-07-11

Affected Products

Linux kernel version 2.6.29 and later

Solution

During off-peak hours, delete and recreate pods in the Deployments that were created before 00:00 on July 11.

  1. Log in to the CCI console. In the navigation pane, choose Workloads > Deployments. On the page displayed on the right, click a Deployment name.
  2. In the Pod List area on the Deployment details page, click Delete in the row where the pod resides. In the dialog box that is displayed, click Yes.

    Figure 1 Deleting a pod
    After the pod is deleted, the Deployment automatically creates new pods, as shown in Figure 2.
    Figure 2 Automatically creating pods

    If there are multiple pods in a Deployment, delete them individually. That is, delete a pod only after the previous pod is successfully re-created. Otherwise, services will be affected.

Appendix: Introduction to TCP SACKs

TCP is a connection oriented protocol. When two parties wish to communicate over a TCP connection, they establish a connection by exchanging certain information such as requesting to initiate (SYN) a connection, initial sequence number, acknowledgment number, maximum segment size (MSS) to use over this connection, and permission to send and process Selective Acknowledgements (SACKs). This connection establishment process is known as 3-way handshake.

TCP sends and receives user data by a unit called segment. A TCP segment consists of TCP Header, Options and user data. Each TCP segment has a Sequence Number (SEQ) and Acknowledgment Number (ACK).

These SEQ & ACK numbers are used to track which segments are successfully received by the receiver. ACK number indicates the next expected segment by the receiver.

Example:

User A sends 1 kilobyte of data through 13 segments of 100 bytes each. There are 13 segments in total because each segment has a TCP header of 20 bytes. On the receiving end, user B receives segments 1, 2, 4, 6, and 8-13. Segments 3, 5, and 7 are lost, and are not received by user B.

By using ACK numbers, user B will indicate that it is expecting segment 3, which user A understands as none of the segments after 2 were received by user B. Then user A will retransmit all the segments from 3 onwards, even though segments 4, 6, and 8-13 were successfully received by user B. User B has no way to indicate this to user A. This leads to an inefficient usage of the network.