QUIC 動作：修補廣播位址放大漏洞

一組匿名安全研究人員最近聯絡了 Cloudflare，他們透過 QUIC 網際網路衡量研究發現了一個廣播放大漏洞。我們的團隊透過網際網路「公開漏洞懸賞」計畫與這些研究人員合作，努力全面修補影響我們基礎架構的危險漏洞。

收到有關該漏洞的通知後，我們實施了緩解措施來幫助保護我們的基礎架構。根據我們的分析，我們已完全修補此漏洞，且放大媒介不再存在。

QUIC 是一種預設加密的網際網路傳輸通訊協定。它提供與 TCP（傳輸控制通訊協定）和 TLS (Transport Layer Security) 等效的功能，同時使用更短的交握序列，幫助減少連線建立時間。QUIC 透過 UDP (User Datagram Protocol) 執行。

研究人員發現，以廣播 IP 目的地位址為目標的單一用戶端 QUIC 初始封包可能會觸發大量初始封包回應。這表現為伺服器 CPU 放大攻擊和反射放大攻擊。

使用 TCP 和 TLS 時，有兩次交握互動。首先是 TCP 3 向傳輸交握。用戶端向伺服器傳送 SYN 封包，伺服器使用 SYN-ACK 回應用戶端，然後用戶端使用 ACK 進行回應。此過程會驗證用戶端 IP 位址。第二次是 TLS 安全性交握。用戶端將 ClientHello 傳送至伺服器，伺服器執行一些加密操作，並以包含伺服器憑證的 ServerHello 進行回應。用戶端會驗證憑證、確認交握並傳送應用程式流量（例如 HTTP 要求）。

QUIC 遵循類似的過程，但是由於傳輸和安全性交握結合在一起，因此序列更短。用戶端向伺服器傳送包含 ClientHello 的初始封包，伺服器執行一些加密操作，並使用包含具有伺服器憑證之 ServerHello 的初始封包進行回應。用戶端驗證憑證，然後傳送應用程式資料。

QUIC 交握在開始安全性交握之前不需要驗證用戶端 IP 位址。這意味著存在攻擊者可能偽造用戶端 IP 並導致伺服器執行加密工作並將資料傳送到目標受害者 IP（又稱反射攻擊）的風險。RFC 9000 仔細描述了這種風險並提供了降低風險的機制（請參閱第 8 節和第 9.3.1 節）。在用戶端位址得到驗證之前，伺服器採用反放大限制，傳送的位元組數最多為所接收位元組數的 3 倍。此外，伺服器可以透過重試封包進行回應，在進行加密交握之前啟動位址驗證。然而，重試機制為 QUIC 交握序列增加了額外的往返，從而抵消了其與 TCP 相比的一些優勢。現實世界的 QUIC 部署使用一系列策略和啟發式方法來偵測流量負載並啟用不同的緩解措施。

為了瞭解研究人員如何在已有這些 QUIC 防護機制的情況下觸發放大攻擊，我們首先需要深入瞭解 IP 廣播的運作方式。

在網際網路通訊協定版本 4 (IPv4) 定址中，任何給定子網路中的最終位址都是特殊的廣播 IP 位址，用於向 IP 位址範圍內的每個節點傳送封包。同一子網路內的每個節點都會接收傳送到廣播位址的任何封包，使一個傳送者傳送的訊息可能被數百個相鄰節點「聽到」。大多數連線網路的系統預設會啟用此行為，這對於發現相同 IPv4 網路內的裝置至關重要。

廣播位址本質上存在 DDoS 放大風險；每傳送一個封包，都有數百個節點需要處理流量。

為了對抗廣播位址帶來的風險，大多數路由器預設拒絕來自其 IP 網路外部的封包，這些封包以它們本機連接之網路的廣播位址為目標。廣播封包只允許在同一個 IP 子網路內轉寄，防止來自網際網路的攻擊針對全球的伺服器。

當給定路由器未直接連接到給定子網路時，通常不會套用相同的技術。只要位址在本機不被視為廣播位址，邊界閘道通訊協定 (BGP) 或其他路由通訊協定就會繼續將來自外部 IP 的流量路由到子網路中的最後一個 IPv4 位址。本質上，這意味著「廣播位址」僅在透過乙太網路連接在一起的路由器和主機的本機範圍內相關。對於網際網路上的路由器和主機來說，廣播 IP 位址的路由方式與任何其他 IP 的路由方式相同。

每個 Cloudflare 伺服器都應能夠從 Cloudflare 網路中的每個網站提供內容。由於我們的網路使用 Anycast 路由，每個伺服器都必須監聽我們網路上使用的每個 Anycast IP 位址（並能夠從其傳回流量）。

為此，我們利用每個伺服器上的回送介面。與實體網路介面不同，當繫結至回送介面時，給定 IP 位址範圍內的所有 IP 位址都可供主機使用（並將由核心在本機處理）。

其運作機制很簡單。在傳統的路由環境中，採用最長前置詞比對來選擇路由。在最長前置詞比對下，將選擇指向更具體的 IP 位址區塊（例如 192.0.2.96/29，8 個位址範圍）的路由，而不是指向不太具體的 IP 位址區塊（例如 192.0.2.0/24，256 個位址範圍）的路由。

雖然 Linux 使用最長前置詞比對，但它會在立即搜尋相符項之前查閱額外的步驟：路由原則資料庫 (RPDB)。RPDB 包含路由表清單，其中可能包含路由資訊及其各自的優先順序。預設 RPDB 如下所示：

$ ip rule show
0:	from all lookup local
32766:	from all lookup main
32767:	from all lookup default

Linux 將按數字升序查詢每個路由表，以嘗試找到相符的路由。找到一個之後，將終止搜尋並立即使用該路由。

如果您以前使用過 Linux 上的路由規則，那麼您可能很熟悉 main 表格的內容。與名為「default」的資料表相反，「main」通常充當預設查閱表格。它也包含傳統上與路由表資訊相關的內容：

$ ip route show table main
default via 192.0.2.1 dev eth0 onlink
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.2

然而，這並不是給定查找將查閱的第一個路由表，第一個路由表是本機表格：

$ ip route show table local
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 192.0.2.2 dev eth0 proto kernel scope host src 192.0.2.2
broadcast 192.0.2.255 dev eth0 proto kernel scope link src 192.0.2.2

在表格中，我們看到了兩種新類型的路由——本機路由和廣播路由。顧名思義，這些路由決定了兩個截然不同的功能：在本機處理的路由和將導致廣播封包的路由。本機路由提供所需的功能——任何帶有本機路由的前置詞都會具有核心處理的範圍內的所有 IP 位址。廣播路由將導致封包被廣播到給定範圍內的所有 IP 位址。當 IP 位址繫結到介面時，會自動新增這兩種類型的路由（並且，當範圍繫結到回送 (lo) 介面時，範圍本身將被新增為本機路由）。

QUIC 的部署高度依賴於它們所在的負載平衡和封包轉寄基礎架構。儘管 QUIC 的 RFC 描述了風險和緩解措施，但根據伺服器部署的性質，仍然可能存在攻擊媒介。報告研究人員研究了網際網路上的 QUIC 部署，發現向 Cloudflare 的一個廣播位址傳送 QUIC 初始封包會觸發大量回應。回應資料總量超過了 RFC 的 3 倍放大限制。

查看 Cloudflare 範例系統的本機路由表，我們發現了一個潛在的罪魁禍首：

$ ip route show table local
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 192.0.2.2 dev eth0 proto kernel scope host src 192.0.2.2
broadcast 192.0.2.255 dev eth0 proto kernel scope link src 192.0.2.2
local 203.0.113.0 dev lo proto kernel scope host src 203.0.113.0
local 203.0.113.0/24 dev lo proto kernel scope host src 203.0.113.0
broadcast 203.0.113.255 dev lo proto kernel scope link src 203.0.113.0

在此範例系統上，Anycast 前置詞 203.0.113.0/24 已透過使用標準工具繫結到回送介面 (lo)。該工具嚴格遵循 IPv4 標準，為介面指派了兩種特殊類型的路由：用於 IP 範圍本身的本機路由和用於範圍內最終位址的廣播路由。

雖然會按預期對前往我們路由器直連子網路廣播位址的流量進行篩選，但針對我們路由之 Anycast 前置詞的廣播流量仍會自行到達我們的伺服器。通常，到達回送介面的廣播流量幾乎不會引起問題。繫結到整個範圍內特定連接埠的服務將接收傳送到廣播位址的資料並繼續正常運作。不幸的是，當打破正常的預期時，這個相對簡單的特性就會失效。

Cloudflare 的前端由多個 Worker 處理序組成，每個處理序獨立地繫結至 UDP 連接埠 443 上的整個 Anycast 範圍。為了讓多個處理序能夠繫結到同一個連接埠，我們使用 SO_REUSEPORT 通訊端選項。雖然 SO_REUSEPORT 有其他好處，但它也會導致傳送到廣播位址的流量被複製到每個接聽程式。

每個 QUIC 伺服器 Worker 都獨立運作。每一個都對同一個用戶端 Initial 做出反應，在伺服器端重複工作並向用戶端的 IP 位址產生回應流量。因此，單個封包就可能觸發顯著的放大。雖然具體情況會因實作而異，但在 128 核心系統上，典型的每個核心一個接聽程式堆疊（這會為回應假定的逾時而傳送重試）可能導致對傳送到廣播位址的每個封包產生並傳送 384 個回覆。

儘管研究人員展示了針對 QUIC 的這種攻擊，但底層漏洞可能會影響以相同方式使用通訊端的其他 UDP 要求/回應通訊協定。

作為一種通訊方法，廣播通常不適合用於 Anycast 前置詞。因此，緩解該問題的最簡單方法就是針對每個範圍中的最終位址停用廣播功能。

理想情況下，這可以透過修改我們的工具來實現，僅在本機路由表中新增本機路由，而完全跳過廣播路由的包含。不幸的是，執行此操作的唯一可行機制是修補和維護我們自己的 iproute2 套件內部分支，但這對於當前的問題來說是一個相當麻煩的解決方案。

因此，我們決定專注於移除路由本身。與任何其他路由類似，可以使用標準工具將其移除：

$ sudo ip route del 203.0.113.255 table local

為了大規模實現這一點，我們對部署系統進行了相對較小的變更：

  {%- for lo_route in lo_routes %}
    {%- if lo_route.type == "broadcast" %}
        # All broadcast addresses are implicitly ipv4
        {%- do remove_route({
        "dev": "lo",
        "dst": lo_route.dst,
        "type": "broadcast",
        "src": lo_route.src,
        }) %}
    {%- endif %}
  {%- endfor %}

這樣做之後，我們可以有效地確保移除連接到回送介面的所有廣播路由，確保同等對待規範定義的廣播位址與範圍內的任何其他位址，從而降低風險。

雖然該漏洞明確影響了我們 Anycast 範圍內的廣播位址，但它可能會擴展到我們的基礎架構之外。如果未採取緩解措施，那麼只要基礎架構符合特定的嚴格技術標準（基於 UDP 的多 Worker、多接聽程式服務，繫結到附加了可路由 IP 前置詞之機器上的所有 IP 位址，並以這樣的方式暴露廣播位址），就會受到影響。我們鼓勵網路管理員和安全專業人員評估他們的系統，尋找可能存在本機放大攻擊媒介的設定。