信息來源：FreeBuf

Cloudflare是一家位于美國的網(wǎng)絡(luò)安全服務(wù)商，為包括Uber（優(yōu)步），F(xiàn)itbit，1password等在內(nèi)的眾多公司提供網(wǎng)站安全管理，性能優(yōu)化等服務(wù)。近日，Google安全人員在研究中發(fā)現(xiàn)：某些情況下，Cloudflare的系統(tǒng)可能會將服務(wù)器內(nèi)存中的數(shù)據(jù)（包括cookie，API密鑰和用戶密碼等）泄露到網(wǎng)頁中——這可謂是數(shù)據(jù)泄漏的大事。由于會讓人回憶起當(dāng)年OpenSSL的“心臟滴血”事件，也有評論將這次事件稱作“云出血（cloudbleed）”。

這就意味著：當(dāng)用戶訪問由Cloudflare提供支持的網(wǎng)站時(shí)，可能隨機(jī)獲取到他人網(wǎng)絡(luò)會話（session）中的敏感信息——好比你在一家餐廳里剛剛就座，服務(wù)員不僅給你遞上了菜單，還贈送了其他某個倒霉客人的錢包。沒錯，這位服務(wù)員就受雇于Cloudflare。

無意發(fā)現(xiàn)

這一問題是由Google Project Zero安全團(tuán)隊(duì)（該團(tuán)隊(duì)似乎長時(shí)間專注于漏洞發(fā)掘，我們曾前不久報(bào)道過他們公布了一個影響Windows GDI庫的漏洞）的漏洞獵人（bughunter，也就是國內(nèi)的白帽子）Tavis Ormandy首先發(fā)現(xiàn)的。當(dāng)時(shí)他在搞一個業(yè)余項(xiàng)目，無意間在Google搜索引擎的緩存頁面中發(fā)現(xiàn)了包含完整的https請求，cookie，API密鑰和密碼在內(nèi)的大量數(shù)據(jù)。經(jīng)過確認(rèn)后他通知了Cloudflare，后者則迅速成立了團(tuán)隊(duì)調(diào)查此事。

在一開始，Ormandy懷疑是Cloudflare一款叫做ScrapeShield的應(yīng)用程序（該程序本是設(shè)計(jì)用來防御爬蟲大量復(fù)制網(wǎng)站信息）引發(fā)了數(shù)據(jù)泄露（點(diǎn)擊查看Ormandy發(fā)布的公告），并在推特上表示他發(fā)現(xiàn)了來自各大交友網(wǎng)站的私密信息，知名聊天服務(wù)網(wǎng)站的信息和在線密碼管理器的數(shù)據(jù)等。

后來隨著Cloudflare調(diào)查的深入，他們發(fā)現(xiàn)事情并沒有那么簡單——這種情況已經(jīng)悄無聲息地持續(xù)幾個月了。

罪魁禍?zhǔn)?/span>

Cloudflare在上周四公布的一份報(bào)告（點(diǎn)擊查看）中給出了調(diào)查結(jié)果：該事件是由一個編程錯誤引起，主要體現(xiàn)在Email Obfuscation、Server-Side Excludes和Automatic HTTPS Rewrites這三個功能上。

原來，在此之前Cloudflare曾為其邊緣服務(wù)器開發(fā)一個新的HTML解析器。該解析器用Ragel（一種有限狀態(tài)機(jī)編譯器）編寫，后轉(zhuǎn)換成C語言源碼。這段代碼存在一個緩沖區(qū)溢出漏洞，可由網(wǎng)頁上不成對的HTML標(biāo)簽觸發(fā)，本是作為指針檢查機(jī)制來防止內(nèi)存覆蓋的。（如下）

/* generated code. p = pointer, pe = end of buffer */

if( ++p == pe )

   goto_test_eof;

某些情況下，p可能會大于pe，從而避開長度檢查，造成緩沖區(qū)數(shù)據(jù)溢出，最終引起了上文所述的信息泄露。Cloudflare工程主管John Graham-Cumming在調(diào)查報(bào)告中總結(jié)道：

“這個問題的根源在于，緩沖區(qū)末端檢查使用了相等運(yùn)算符（==），導(dǎo)致指針可以跳過這一段。如果能使用>=而不是==，那么至少可以發(fā)現(xiàn)跳過緩沖區(qū)尾部的事件?！?/span>

另據(jù)補(bǔ)充，要致使數(shù)據(jù)泄露，最后的緩沖區(qū)必須以格式錯誤的腳本或img標(biāo)簽結(jié)尾，長度不能超過4KB（否則Nginx會崩潰），并運(yùn)行上述函數(shù)。

為時(shí)已晚？

通常此類泄露的信息會隱藏在網(wǎng)頁源碼中，并不引人注意。這次Ormandy在Google緩存頁面中發(fā)現(xiàn)了這個問題，意味著很可能在此之前一段相當(dāng)長的時(shí)間里，已經(jīng)有大量信息被分散泄露到各處，比如爬蟲程序，甚至不法分子的手里。

這里簡要回顧一下Cloudflare官方報(bào)告中給出的時(shí)間線：

去年9月22日，啟用Automatic HTTP Rewrites函數(shù)

今年1月30日，Server-SideExcludes移至新的解析器

今年2月13日，EmailObfuscation部分移至新解析器

今年2月18日，Google向Cloudflare通報(bào)了此情況

可以看出，早期的數(shù)據(jù)泄露事件可能在去年9月就開始了。官方認(rèn)為，受到?jīng)_擊最大的時(shí)間段可能在今年2月13日開始的4天內(nèi)，因?yàn)楫?dāng)時(shí)Automatic HTTP Rewrites還沒有開始廣泛使用，Server-Side Excludes也只針對惡意IP地址。

不過好在Cloudflare事發(fā)后的應(yīng)對也很迅速。他們在接到通報(bào)的47分鐘內(nèi)就禁用了Email Obfuscation。三個小時(shí)后，對Automatic HTTPS Rewrites采取了同樣的措施。不過對于Server-Side Excludes的終止卻稍顯棘手，Cloudflare表示他們已經(jīng)專門發(fā)布了一個補(bǔ)丁針對此事。GitHub上已經(jīng)發(fā)布了可能受此漏洞影響的網(wǎng)站名單，對于后續(xù)更大范圍的補(bǔ)救措施，相信Cloudflare正在落實(shí)中。目前尚未有確切的大規(guī)模數(shù)據(jù)以此種途徑被不法分子利用的報(bào)道，希望一切還不會為時(shí)太晚。