CVE-2024-38063 的全面分解：Windows TCP/IP 堆疊中的重要威脅

CVE-2024-38063 是一個 Windows TCP/IP 堆疊危機漏洞，CVSS 得分為 9.8，影響 IPv6 封包的處理。遠端攻擊者可利用此漏洞，在處理 IPv6 擴充標頭時利用整數下溢執行惡意程式碼或導致 DoS (阻斷服務)。

由於 IPv6 在大多數現代系統上都是預設啟用的，因此這個零點擊漏洞帶來了很大的風險。因此，所有啟用 IPv6 的 Windows 10、Windows 11 以及 WindowsServer 2008、2012、2016、2019 和 2022 的未修補版本都會受到此 CVE 的攻擊。

Windows TCP/IP 堆疊是作業系統的基礎元件，負責透過傳輸控制通訊協定/網際網路通訊協定 (TCP/IP) 套件進行網路通訊。它處理所有的網路互動，促進裝置間跨區域和全球網路的通訊。

IPv6 是針對 IPv4 的限制而開發的。它引入了各種增強功能，例如通過擴展標頭（extension headers）實現模組化和靈活性。這些位於 IPv6 標頭和有效負載之間的標頭支援可選資料和進階功能。

關鍵 IPv6 延伸標頭包括

• 逐跳選項 (Next Header = 0) 
• 路由標頭 (Next Header = 43) 
• 片段標頭 (Next Header = 44) 
• 目的地選項標頭 (Next Header = 60) 
• 驗證標頭 (AH)（下一個標頭 = 51） 
• 封裝安全有效負載 (ESP) (Next Header = 50) 

每個擴充標頭透過 Next Header 欄位指向下一個標頭，形成一個順序鏈。這種模組化為封包處理程序帶來了複雜性和潛在的攻擊媒介。

當計算產生的值小於資料類型的最小可表示值時，就會發生整數下溢。例如，從一個較小的值減去一個較大的值到一個無符號整數，可能會導致結果變成一個非常大的正值。

當值超過資料類型的最大限制，並「溢出」回最小可表示值（例如 0-10 範圍內的 0）時，就會發生整數溢出。這兩種情況的發生都是由於算術運算中邊界條件處理不當，導致軟體系統出現嚴重漏洞。

收到 IPv6 封包後，Windows 會先解析 IPv6 標頭。接著，IppReceiveHeaderBatch 函式會檢查 Next Header 欄位的值，以便為後續的標頭選擇適當的處理程式。對於鏈中的每個延伸標頭，IppReceiveHeaderBatch 會呼叫相應的例程來處理該特定標頭。

微軟針對 CVE-2024-38063 漏洞所推出的修補程式，已由安全研究員 Marcus Hutchins 詳細檢視過。他的技術文章詳細介紹了此漏洞的根源。以他的發現為基礎，我們的研究員進一步探討了這個問題，以徹底了解這個漏洞。

片段處理中的整數下溢

透過設定 Next Header 欄位為 44，表示 Fragment Header，封包會被 IPv6 片段或重新組合例程處理。當封包到達片段解析器 Ipv6pReceiveFragment() 時，它會指定： 

• 封包大小為零。 
• 片段標頭表示仍有其他資料需要處理。 

在 Ipv6pReceiveFragment() 函式中，fragment_size 的分配大小是從封包大小減去 0x30（封包標頭長度）而計算出來的，沒有經過任何驗證。如果封包大小為零，這個減法會不足溢出，產生一個很大的 16 位元值 (約 0xFFD0 或 65488)，導致解析器在封包的有效邊界外處理過量的記憶體，並導致記憶體損毀。 

從下溢到溢出以及分配中的錯配

Ipv6pReassemblyTimeout() 函式負責在指定時間後清理不完整的 IPv6 片段，使用 16 位元算術來決定緩衝區大小和複製作業。由於上一步的下溢（packet_length 或 fragment_size 變為 0xFFD0），在分配時會發生溢出。  

計算結果會導致暫存器重設為零，導致只分配了 48 位元組的記憶體。然而，由於複製的資料量 (來自 reassembly->payload 的 65,488 位元組) 並不符合所分配的記憶體，因此在核心池中會發生可控制的緩衝記憶體溢出。 

為了試圖重現 CVE-2024-38963 漏洞，我們的研究員製作了一系列畸形封包來利用此漏洞。他們所遵循的程序如下

在基本 IPv6 標頭之後插入 IPv6 目的地選項延伸標頭（類型 60），然後內嵌一個無效選項（例如選項類型 0x81）。 

此操作會強制 Windows 核心 (tcpip.sys) 設定 always_send_icmp = true，並透過 IppSendErrorList() 例程觸發 ICMPv6 錯誤產生。

以這些畸形封包的快速連續湧入目標，增加了核心將多個封包組合成單一 Net-Buffer List (NBL) 的機會。當兩個或更多封包被群組時，易受攻擊的 IppSendErrorList() 環路會被啟動，不正確地重設後續片段中的 DataLength 和 Offset 元資料 (封包大小現在為零)。 

在傳送畸形封包後，會傳送包含 Fragment 延伸標頭的片段化 IPv6 封包。這些片段會使用已損毀的 DataLength 值來處理。 

核心會保留片段 60 秒 (由 Ipv6pReassemblyTimeout 管理) 以允許封包重新組裝。在此超時期間，損毀的 DataLength 值會觸發 Ipv6pReceiveFragment 中的整數下溢，導致計算錯誤（過大）的片段大小。

核心會根據下溢的值來分配堆緩衝區。在重新組合過程中會發生兩種不同的計算：一種是決定記憶體分配大小（由於 16 位元的溢出，該大小變得太小），另一種是使用大的、未滿溢出的值計算複製長度。

此錯誤會導致越界寫入，造成堆陣緩衝記憶體滿溢，惡意使用者可利用此漏洞導致阻斷服務 (DoS) 或遠端程式碼執行。