本文最初發(fā)布于 Daniel Stenberg 的個人博客。

curl 作者 Daniel Stenberg 近日在個人博客分享了一個存在 23.9 年的 curl 漏洞。curl 是常用的命令行工具，用來請求 Web 服務(wù)器，于 1997 年首次發(fā)行。

據(jù) Stenberg 透露，這個漏洞是在 curl 發(fā)布后的第 201 天引入的，但是直到第 8930 天，漏洞才修復(fù)好。一個持續(xù)了 23.9 年的漏洞背后有著怎樣的故事？

一切還得從 1998 年說起。

1998 年 10 月，Stenberg 帶領(lǐng)團(tuán)隊(duì)推出了 curl 4.9 版本。當(dāng)時，聽過或用過 curl 的人還少得可憐。幾個月之后，curl 官網(wǎng)才宣布新版本的下載量達(dá)到了 300。那時，無論從何種意義上講， curl 都還很小眾。

curl 4.9 作為第一個帶有 “cookie 引擎” 的版本，可以接收 HTTP cookie、解析、識別，并在后續(xù)的請求中把 cookie 正確地返回。在 curl 中，處理 cookie 的大部分代碼都是 Stenberg 編寫的。

那會，cookie 還沒有明確的規(guī)范，僅有的一份描述 cookie 工作原理的規(guī)范，是一份由 Netscape 管理的文檔cookie_spec （感興趣的同學(xué)可以戳鏈接查看文檔副本：https://curl.se/rfc/cookie_spec.html）。這份文檔并不完善，有不少信息需要通過查看其它客戶端才能了解到。

Stenberg 在實(shí)現(xiàn)處理 cookie 的代碼時，就是參考了這份文檔以及當(dāng)時瀏覽器的大致處理方式。

此后十年，IETF（互聯(lián)網(wǎng)工程任務(wù)組）一直在努力創(chuàng)建 cookie 規(guī)范，但均以失敗而告終。這些早期 cookie 規(guī)范的創(chuàng)建者可能覺得，他們創(chuàng)建了標(biāo)準(zhǔn)，世界就會情不自禁地遵守它們，但事實(shí)并非如此。cookie 的特殊之處在于，有很多不同的作者、代碼庫和網(wǎng)站實(shí)現(xiàn)了它。因此，很難從根本上改變它們的工作方式。

直到 2011 年，cookie RFC 正式發(fā)布了，它記錄并解釋了 cookie 實(shí)際的使用方式，這可以說是真正意義上的 cookie 規(guī)范。Stenberg 本人也參與了規(guī)范的制定過程，并在其中闡述了自己的觀點(diǎn)和意見。對于這份規(guī)范的內(nèi)容，雖然 Stenberg 并不完全贊同，但與此前的各種 cookie 規(guī)范相比，cookie RFC 的確是一個巨大的進(jìn)步。

一開始，新的 cookie 規(guī)范并沒有給 Stenberg 造成困擾，但很快，規(guī)范的特殊編寫方式讓 Stenberg 倍感頭疼：它針對服務(wù)器如何發(fā)送 cookie 提供了一種字段語法，而針對客戶端應(yīng)該接受什么樣的 cookie 提供了另一種語法。也就是說，同樣的 cookie，需要兩種語法。

這有兩個很直接的缺點(diǎn)：

1. 規(guī)范很難閱讀。你很容易就停留在其中一種語法上，以為那就是適合自己用例的，但卻沒有意識到角色描述是錯誤的。

2. 定義如何發(fā)送 cookie 的語法其實(shí)并不重要，因?yàn)槿绾谓邮蘸吞幚?cookie 都是由客戶端決定的?，F(xiàn)有的大型 cookie 解析器（瀏覽器）有一定程度的自由決定自己接受什么，所以沒人注意，也沒人關(guān)心服務(wù)器是否嚴(yán)格遵守了規(guī)范中的語法。與此同時，cookie 規(guī)范也在持續(xù)更新。從幾年前開始，IETF 就一直在修訂和更新 2011 年的 cookie 規(guī)范，計(jì)劃將世界上一些已實(shí)際投入使用的 cookie 擴(kuò)展添加到規(guī)范中。這項(xiàng) cookie 規(guī)范更新工作被稱為 6265bis。

curl 也同步進(jìn)行更新，以確保符合 RFC 6265bis 草案版本的規(guī)定。

但是，雙重語法仍然是 cookie 規(guī)范文檔中懸而未決的問題。

隨著時間的推移，cookie 的發(fā)展變得緩慢。在過去的幾十年里，HTTP 規(guī)范也就更新了有限的幾次，但值得一提的是，HTTP 服務(wù)器實(shí)現(xiàn)已經(jīng)實(shí)施了更嚴(yán)格的解析策略：

如果傳入的 HTTP 請求看上去“非法”或格式不正確，那么 HTTP 服務(wù)器就會提前拒絕，把它們擋在門外。對于請求中的控制代碼尤其如此。如果你試圖將一個包含控制代碼（這里的控制代碼指的是介于 1 到 31 之間的字節(jié)值，不包括 9，9 是 TAB）的請求發(fā)送到一個相當(dāng)新的 HTTP 服務(wù)器，那么服務(wù)器很可能會拒絕，并返回 400 響應(yīng)代碼。從 2016 年 12 月發(fā)布的 2.4.25 版本開始，HTTP 服務(wù)器 Apache httpd 就默認(rèn)啟用了此行為。最新版本的 Nginx 似乎也是這樣做的。

如果是現(xiàn)在設(shè)計(jì) cookie，那么肯定會有所不同。

設(shè)置 cookie 的網(wǎng)站把 cookie 發(fā)送到客戶端，對于其發(fā)送的每個 cookie，它都會設(shè)置多個屬性。尤其是當(dāng)需要客戶端發(fā)回 cookie 時，它會設(shè)置匹配參數(shù)。

在 cookie 的這些參數(shù)中，其中有一個是 domain，客戶端發(fā)送 cookie 時要匹配它。服務(wù)器www.example.com可以設(shè)置 cookie 的有效范圍為整個example.com域，這時，客戶端在訪問second.example.com 時也會發(fā)送 cookie。也就是說，服務(wù)器可以將 cookie 設(shè)置為適用于“兄弟站點(diǎn)”。

值得一提的是，1998 年添加到 curl 中的 Cookie 代碼在接受內(nèi)容方面相當(dāng)自由，當(dāng)然，多年來也經(jīng)過了不少調(diào)整和完善，不過它始終與現(xiàn)實(shí)世界的網(wǎng)站保持了兼容。對于那部分代碼，Stenberg 修改的主要動力始終是為了使 curl 的 Cookie 處理方式與其他已有的使用 cookie 的代理保持基本一致，并可以互操作。

2022 年 6 月底，Stenberg 收到了一份報告，報告懷疑 curl 中存在安全問題。正是這份報告促使 curl 發(fā)布了 CVE-2022-35252。

事實(shí)證明，源于 1998 年的舊 cookie 代碼，會接受包含控制代碼的 cookie。控制代碼可以是名稱或內(nèi)容的一部分，如果用戶啟用了“cookie 引擎”，那么 curl 就會存儲那些 cookie，并在后續(xù)的請求中將它們發(fā)送回來。

例如，curl 會接受下面這樣的 cookie：

Set-cookie: name^a=content^b; domain=.example.com

^a 和 ^b 表示控制代碼。由于域可以將 cookie 標(biāo)記為適用于其他主機(jī)，所以發(fā)送到域中所有主機(jī)的請求都會包含這個 cookie。

當(dāng) curl 將類似那樣的一個 cookie 發(fā)送到 HTTP 服務(wù)器時，它的外發(fā)請求中會包含下面這樣一個 header 字段：

cookie: name^a=content^b

對此，Apache httpd 及其他服務(wù)器的默認(rèn)配置都會返回 400。一個腳本或應(yīng)用程序在收到這樣的 cookie 后，如果后續(xù)的請求中還繼續(xù)發(fā)送 cookie，就會遭到拒絕。

Stenberg 復(fù)盤后發(fā)現(xiàn)，cookie 規(guī)范 RFC 6265 5.2 節(jié)確實(shí)說了，客戶端應(yīng)該丟棄包含控制代碼的 cookie，但這部分對用戶來說理解起來比較難，需要對文檔有深入的研究才能發(fā)現(xiàn)。此外，規(guī)范并沒有提及“控制代碼”或是字節(jié)值范圍。

Stenberg 認(rèn)為，要弄清楚主流瀏覽器是怎么做的還是比較容易的，因?yàn)樗鼈兊脑创a很容易獲得。事實(shí)證明，Chrome 和 Firefox 都已經(jīng)忽略了包含以下任何字節(jié)的傳入 cookie：

%01-%08 / %0b-%0c / %0e-%1f / %7f

其中不包含 %09（TAB）和 %0a / %0d（行結(jié)束符）。

Bug 修復(fù)方面，Stenberg 表示，curl 的修復(fù)補(bǔ)丁處理方式非常簡單：拒絕包含一個或多個禁用字節(jié)值的 cookie 字段。Stenberg 認(rèn)為，這種修改基本是沒有風(fēng)險的。

推算起來，有漏洞的代碼從 curl 4.9 版本開始就一直存在，curl 7.85.0 版本才完成修復(fù)。整個歷程有 8729 天（23.9 年）。也就是說，這個 Bug 是在項(xiàng)目發(fā)布的第 201 天引入的，到第 8930 天才修復(fù)。

Stenberg 認(rèn)為，代碼在發(fā)布時是沒什么問題的，并且在用戶的使用過程中，也基本沒有產(chǎn)生什么問題。它的問題出在，HTTP 服務(wù)開始拒絕可能的惡意 HTTP 請求時。如此一來，這段代碼就變成了一種拒絕服務(wù)，這或多或少會帶來一些副作用。

或許，這個 Bug 誕生于 RFC 6265 發(fā)布之時?；蛟S，它誕生于 HTTP 服務(wù)器開始拒絕這些請求時。不管怎樣，這個 Bug 創(chuàng)造了一個新的項(xiàng)目記錄：它是第四個被發(fā)現(xiàn)之前存在了 8000 多天的 Bug。