Netflix公司 幾個關鍵的 在 Linux 和 FreeBSD TCP 堆疊中，它允許您在處理特殊設計的 TCP 封包（死亡封包）時遠端啟動核心崩潰或導致過多的資源消耗。 問題 TCP 封包中最大資料區塊大小（MSS，最大段大小）和選擇性連線確認機制（SACK，TCP 選擇性確認）的處理程序中的錯誤。
(SACK Panic) - 從 2.6.29 開始，Linux 核心中出現的一個問題，允許您因處理程序中的整數溢出而發送一系列 SACK 封包，從而導致核心恐慌。 為了進行攻擊，只需將 TCP 連接的 MSS 值設為 48 位元組（下限將段大小設為 8 位元組）並發送以某種方式排列的 SACK 封包序列。
作為安全解決方法，您可以停用 SACK 處理（將 0 寫入 /proc/sys/net/ipv4/tcp_sack）或 低 MSS 連線（僅當 sysctl net.ipv4.tcp_mtu_probing 設定為 0 時有效，可能會中斷一些正常的低 MSS 連線）；
（SACK 緩慢）- 導致 SACK 機制中斷（使用低於 4.15 的 Linux 核心時）或資源消耗過多。 當處理特製的 SACK 封包時會出現此問題，可用於對重傳佇列進行分段（TCP 重傳）。 安全解決方法與先前的漏洞類似；
(SACK Slowness) - 讓您在處理單一 TCP 連線內的特殊 SACK 序列時導致發送封包對應的碎片，並導致執行資源密集型清單枚舉操作。 該問題出現在具有 RACK 丟包偵測機制的 FreeBSD 12 中。 作為解決方法，您可以停用 RACK 模組；
- 攻擊者可以導致Linux核心將回應分割成多個TCP段，每個段僅包含8位元組數據，這可能導致流量顯著增加、CPU負載增加和通訊通道堵塞。 建議將其作為保護的解決方法。 低 MSS 的連接。
在 Linux 核心中，這些問題已在版本 4.4.182、4.9.182、4.14.127、4.19.52 和 5.1.11 中解決。 FreeBSD 的修復程序如下： 。 在發行版中，核心軟體包的更新已經發布了 , , 。 準備過程中的修正 , и .
來源： opennet.ru
