Linux TCP bug could put you in a SACK
Linux is the most used kernel in the world (if we don’t consider MINIX), it powers many devices such as Android phones, supercomputers, server clusters and (the brave few) desktops. A new bug affecting SACKs was discovered in the networking stack inside the Linux Kernel, and this one can literally cause panic.
Linux and TCP bugs
Linus’s law states: “given enough eyeballs, all bugs are shallow”, but in Linux case, in the networking stack, that doesn’t seem to be the case. In the past many bugs were discovered in the Linux kernel, and probably many more will be. But the ones affecting networking are usually nasty because they may be exploited remotely. Such as this one which allowed hijacking. It seems that we are not as secure as we thought, but again, that’s just natural. No matter how many eyes, Dijkstra said “Program testing can be used to show the presence of bugs, but never to show their absence!”.
Be prepared to be in a SACK
The new exploit has been assigned three CVEs: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479. The first two exploit the Linux handling of TCP packets called SACKs, the third one leverages a parameter: Maximum Segment Size (MSS).
SACKs were defined in RFC-2018, they stand for Selective Acknowledgement. A mechanism introduced to prevent overhead and useless network traffic. TCP divides data into segments with a maximum size (MSS). Sometimes (read: may happen more often than you believe) not all the segments make it to the destination. This leaves the receiver with an incomplete message. But TCP is a reliable protocol that allows the receiver to request the message again. Without SACKs the receiver would have to request all the segments again, and the sender to send them again even if only one segment was missing. With SACKs enabled the receiver can request only the missing segment thus reducing traffic and communication overhead.
When the Linux kernel handles SACKs it stores them in a queue: SKB (Socket Buffer). The structure can hold up to 17 fragments (queued entries) at all the times. Given the right conditions (minimum MSS: 48 bytes), and a high number of packets being held in the SKB, the structure could be completely filled and reach its maximum capacity. Past that point the structure will overflow and trigger the kernel panic. The kernel panic will cause the server to be unresponsive and will need to be restarted manually.
Patches
Here you can monitor the state of the issue as it is processed by the major Linux distributions:
- 2020 A year in review for Marksei.com - 30 December 2020
- Red Hat pulls the kill switch on CentOS - 16 December 2020
- OpenZFS 2.0 released: unified ZFS for Linux and BSD - 9 December 2020
Recent Comments