Cloudflare Proxies記憶體洩漏，又稱“Cloudbleed”

一個緩衝區溢位缺陷導致了資料洩露， 少量發往Cloudflare proxies的請求拿到了其他不相關請求資料， 包括潛在的敏感性資料， 例如密碼、其他秘密資訊。 這個問題已經被命名為“Cloudbleed”， 由穀歌零漏洞專案組研究員Tavis Ormandy發現並記錄。 部署了修復程式並嘗試清空搜尋引擎緩存之後， Cloudflare的John Graham-Cumming在一篇博客文章裡詳細地做出了解釋。 儘管有一些敏感性資料洩漏， Cloudflare的創始人和CEO Matthew Prince在推特發表申明“我認為我們很大程度上避開了實際影響”。

在這篇解釋性博客文章， 以及CEO Matthew Prince致客戶的郵件裡， Cloudflare費盡心力強調要保護好SSL私密金鑰， 因為這些私密金鑰被用於單獨隔離的Nginx實例中。

這次洩漏是由於Nginx外掛程式組合引起的， Cloudflare使用這些外掛程式去處理客戶請求。 新引入的外掛程式讓一個隱藏在老外掛程式裡的問題暴露了出來， 在解析不規範的HTML文檔時會出現問題。

這次事故預計已經影響了2017年2月13日到2017年2月18日之間， 通過Cloudflare proxies的每3,300,000個HTTP請求當中的1個。 安全專家Troy Hunt在他的文章“實際思考CloudBleed”中指出， 這一可能性可以和“中大獎”相媲美， 雖然這裡的問題有雙重性：首先， 製造洩漏的網站本身也是無辜的受害網站， 它又進一步放大了洩露問題， 其次， 我們沒有辦法“檢查資訊”， 確保是否是洩漏受害者（同樣適用於調用Cloudflare和它們的訪客網站）。 Tony指出這些訪客或者例如博客一類的公共網站沒有什麼可以擔心的，

對於那些對資料敏感的網站來說就不一樣了， 例如約會網站和銀行。 AgileBits費盡全力指出1-Password是安全的， 同時Monzo指出這次問題只是潛在地影響了開發人員API使用者的一小部分。

Cloudflare推遲了通知時間， 同時聯合搜尋引擎一起清空緩存資料， 追蹤從161個獨立功能變數名稱發送過來的770個請求URI。 這樣做的目的是防止通過進入搜尋引擎緩存的方式使用私人資料。 雖然Cloudflare和Google從一開始就進行合作， 這個問題看起來有點緊迫， 清除行動可能沒有像最初預期的那麼快完成。

Graham-Cumming的博客文章建議事故修復之後， 通過非常容易理解的日誌引導， 允許Cloudflare確定問題的範圍和規模， 並且設定補救措施的目標。 就像最初希望的那樣達到目標。 它的觀點是，

Cloudflare躲過的風險很有可能是真實的， 不僅僅危害了Cloudflare和它們的客戶， 也對大量的web用戶產生危害。 Cloudflare預估可以在大於所有web峰值的10%的情況下正常工作， 而且對於大多數人來說， 不可能一天內不使用Cloudflare， 因為它為很多程式提供後臺支撐。 如果這個缺陷已經明晰， 那麼它應該很快就會被注意到， 但是也可能對於Cloudflare和它的客戶造成更大的傷害。 使用類似於Cloudflare一類服務的風險正在增加， 它們充當了web使用者和真實訪問服務之間的“裁判”角色， 必須找到平衡方式， 就好像加強羊群內部的群體免疫能力一樣。 事情的另一面， 很少有組織願意對於自身基礎設施這類錯誤進行快速而徹底地回應， 就像Cloudflare做的那樣。 他們使用的全域特性標誌允許他們快速地把引起問題的堆疊資訊移除掉。

事故發生後我們通常會問：“我是不是應該修改密碼？”， 輿論（反感風險）的回答是應該， 安全比到時候說抱歉有用得多。 總的來說， 任何一個人的私密資訊被以一個可以利用的方式洩漏的機會非常低（可能遠遠低於相同的私密資訊通過惡意軟體或者其他類似方式洩漏的可能性）。 Cloudflare和更廣義的網路安全社區已經從這起事故中學到了很多， 但是當類似於C語言這樣的不安全語言被繼續用在對安全敏感的基礎設施領域的話， 我們可以確信類似的事故會再次發生（是的， 再一次發生時goto陷阱仍然會是元兇）。

感謝薛命燈對本文的審校。