一、前言

上星期五，來自谷歌Project Zero組織的Tavis Ormandy聯(lián)系Cloudflare，報(bào)告了我們的邊界服務(wù)器的一個(gè)安全問題。他看到經(jīng)過Cloudflare的一些HTTP請(qǐng)求返回了崩潰的網(wǎng)頁。

它出現(xiàn)在一些不尋常的情況下，在下面我將詳細(xì)介紹，我們的邊界服務(wù)器運(yùn)行時(shí)緩沖區(qū)越界了，并返回了隱私信息，如 HTTP cookies，認(rèn)證令牌，HTTP POST體和其他敏感數(shù)據(jù)的內(nèi)存。并且有些數(shù)據(jù)會(huì)被搜索引擎緩存。

為了避免懷疑，Cloudflare客戶的SSL私鑰沒有泄漏。Cloudflare總是通過一個(gè)隔離的Nginx實(shí)例來結(jié)束SLL連接，因此不受這個(gè)bug影響。

我們快速的確認(rèn)了這個(gè)問題，并關(guān)閉了3個(gè)Cloudflare功能(郵件混淆，服務(wù)端排除和自動(dòng)HTTPs重寫)，這些都用來了相同的HTML解析器鏈，會(huì)導(dǎo)致泄漏。這樣在一個(gè)HTTP響應(yīng)中就不會(huì)有內(nèi)存返回了。

因?yàn)檫@個(gè)bug的嚴(yán)重性，來自San Francisco和 London的軟件工程師、信息安全和操作的交叉功能團(tuán)隊(duì)充分了解了潛在的原因，為了降低內(nèi)存泄漏的影響，和谷歌和其他搜索引擎團(tuán)隊(duì)一起將緩存的HTTP響應(yīng)移除了。

擁有一個(gè)全球化的團(tuán)隊(duì)，每12小時(shí)為間隔，每天24小時(shí)交替解決這個(gè)問題。團(tuán)隊(duì)持續(xù)的努力確保了問題的圓滿解決。作為服務(wù)的一個(gè)優(yōu)勢(shì)是這個(gè)bug從報(bào)告到解決，花了幾分鐘到幾小時(shí)，而不是幾個(gè)月。針對(duì)這樣的bug部署修復(fù)方案的工業(yè)標(biāo)準(zhǔn)通常是3個(gè)月;我們?cè)谛∮?個(gè)小時(shí)就圓滿解決，47分鐘內(nèi)就緩解了bug。

這個(gè)bug是嚴(yán)重的，因?yàn)樾孤┑膬?nèi)存包含了隱私信息，并且還會(huì)被搜索引擎緩存。我們還沒有發(fā)現(xiàn)這個(gè)bug的漏洞利用或者它們存在的報(bào)告。

影響最大的時(shí)期是2月13日到2月18號(hào)，通過Cloudflare的每3,300,000個(gè)HTTP請(qǐng)求中約有1個(gè)可能導(dǎo)致內(nèi)存泄漏(約為請(qǐng)求的0.00003%)。

我們感謝它由世界頂級(jí)安全研究團(tuán)隊(duì)發(fā)現(xiàn)并報(bào)告給我們。

本文很長(zhǎng)，但是作為我們的傳統(tǒng)，我們傾向于對(duì)我們的服務(wù)出現(xiàn)的問題保持開放和技術(shù)上的詳細(xì)描述。

二、運(yùn)行時(shí)解析并修改HTML

很多Cloudflare服務(wù)依賴通過我們的邊界服務(wù)器時(shí)解析和修改HTML頁面。例如，我們能通過修改HTML頁面來插入谷歌分析標(biāo)簽，安全的重寫http://鏈接為https://，排除來自機(jī)器人的部分頁面，模糊電子郵件地址，啟用AMP等。

為了修改頁面，我們需要讀取并解析HTML以發(fā)現(xiàn)需要修改的元素。因?yàn)樵贑loudflare的早期，我們已經(jīng)使用了用Ragel編寫的解析器。一個(gè)獨(dú)立的.rl文件包含一個(gè)HTML解析器，被用來在Cloudflare平臺(tái)修改HTML。

大約一年前，我們認(rèn)為Ragel解析器維護(hù)起來太復(fù)雜，并且我們開始寫一個(gè)新的解析器(cf-html)來替代它。這個(gè)解析器能正確處理HTML5，而且非常非?？烨乙拙S護(hù)。

我們首先將這個(gè)解析器用于自動(dòng)HTTP重寫功能，并一直慢慢地遷移cf-html替換Ragel。

Cf-html和老的Ragel解析器都作為Nginx模塊實(shí)現(xiàn)，并編譯到我們的Nginx構(gòu)建中。這個(gè)Nginx過濾模塊解析包含HTML響應(yīng)的緩沖區(qū)(內(nèi)存塊)，做出必要的修改，并將緩沖區(qū)傳遞給下一個(gè)過濾模塊。

這樣，引起內(nèi)存泄漏的bug在我們的Ragel解析器中已存在多年，但是因?yàn)槲覀儍?nèi)部Nginx使用緩沖區(qū)的方式，并沒有內(nèi)存泄漏。Cf-html巧妙的改變了緩沖去，導(dǎo)致在cf-html中不會(huì)有問題。

因?yàn)槲覀冎懒诉@個(gè)bug是由激活cf-html引起的(但是之前我們知道為什么)，我們禁用了使用它的3個(gè)功能。Cloudflare每個(gè)功能都有一個(gè)相應(yīng)的功能標(biāo)志，我們稱之為全局殺手。我們?cè)谑盏絾栴}細(xì)節(jié)報(bào)告后的47分鐘時(shí)啟用了郵件混淆的全局殺手，并在3小時(shí)5分鐘后關(guān)閉了自動(dòng)HTTP重寫。郵件混淆功能在2月13號(hào)已經(jīng)修改了，并且是內(nèi)存泄漏的原因，因此禁用它快速地阻止了幾乎所有的內(nèi)存泄漏。

在幾秒內(nèi)，這些功能在全球范圍內(nèi)被禁用。我們確定沒有通過測(cè)試URI來泄漏內(nèi)存，并且谷歌的二次校驗(yàn)也一樣。

然后，我們發(fā)現(xiàn)了第三個(gè)功能(服務(wù)端排除)也有這個(gè)漏洞，但是沒有全局殺手開關(guān)(它非常老，在全局殺手之前實(shí)現(xiàn))。我們?yōu)榉?wù)端排除實(shí)現(xiàn)了一個(gè)全局殺手，并全球部署補(bǔ)丁。從發(fā)現(xiàn)服務(wù)端排除是個(gè)問題到部署補(bǔ)丁只花了3個(gè)小時(shí)。然而，服務(wù)端排除很少使用，且只針對(duì)對(duì)惡意的IP地址才激活。

三、bug的根因

Ragel代碼轉(zhuǎn)化為C代碼，然后編譯。這個(gè)C代碼使用經(jīng)典的C方法，指向HTML文檔的指針被解析，并且Ragel自身給用戶提供了針對(duì)這些指針大量的控制權(quán)。因?yàn)橐粋€(gè)指針錯(cuò)誤導(dǎo)致的bug的產(chǎn)生。

/* generated code */ 
if ( ++p == pe ) 
    goto _test_eof; 

bug的根因是，使用等于運(yùn)算符來校驗(yàn)是否到達(dá)緩沖區(qū)的末端，并且指針能夠步過緩沖去末端。這是熟知的緩沖去溢出。使用>=代替==來做檢驗(yàn)，將跳過緩沖區(qū)末端。這個(gè)等于校驗(yàn)由Ragel自動(dòng)生成，不是我們編寫的代碼。意味著我們沒有正確的使用Ragel。

我們編寫的Ragel代碼包含了一個(gè)bug，其能引起指針越界且給了等號(hào)校驗(yàn)造成緩沖區(qū)溢出的能力。

下面是Ragel代碼的一段代碼，用來獲取HTML標(biāo)簽中的一個(gè)屬性。第一行說的是它試圖找到更多以空格，正斜杠或>結(jié)尾的unquoted_attr_char。(:>>是連接符)

script_consume_attr := ((unquoted_attr_char)* :>> (space|'/'|'>')) 
>{ ddctx("script consume_attr"); } 
@{ fhold; fgoto script_tag_parse; } 
$lerr{ dd("script consume_attr failed"); 
       fgoto script_consume_attr; }; 

如果一個(gè)屬性格式良好，則Ragel解析器跳轉(zhuǎn)到@{}代碼塊。如果解析屬性失敗(就是我們今天討論的bug的開始)，那么到$lerr{}。

舉個(gè)例子，在實(shí)際情況下(細(xì)節(jié)如下)，如果web頁面以錯(cuò)誤的HTML標(biāo)簽結(jié)尾，如：

<script type= 

$lerr{ }塊將執(zhí)行，并且緩沖去將溢出。這個(gè)例子中$lerr執(zhí)行dd(“script consume_attr failed”);(這是個(gè)調(diào)試語句)，然后執(zhí)行fgoto script_consume_attr;(轉(zhuǎn)移到script_consume_attr去解析下一個(gè)屬性)。

從我們的分析中看，這樣錯(cuò)誤的標(biāo)簽出現(xiàn)在大約0.06%的網(wǎng)站中。

如果你觀察仔細(xì)，你可能已經(jīng)注意到@{ }也是一個(gè)fgoto，但是在它之前執(zhí)行了fhold，并且$lerr{ }沒有。它沒有fhold導(dǎo)致了內(nèi)存泄漏。

在內(nèi)部，生成的C代碼有一個(gè)指針p，指向HTML文檔中正在檢測(cè)的字符。Fhold等價(jià)于p--，并且是必要的。因?yàn)楫?dāng)錯(cuò)誤條件發(fā)生時(shí)，p將指向?qū)е聅cript_consume_attr失敗的字符。

并且它非常重要，因?yàn)槿绻@個(gè)錯(cuò)誤條件發(fā)生在包含HTML文檔的緩沖區(qū)的末尾，則p將在文檔末端的后面(p將是pe+1)，且達(dá)到緩沖區(qū)末尾的校驗(yàn)將失敗，p將在緩沖去外部運(yùn)行。

添加一個(gè)fhold到錯(cuò)誤處理函數(shù)中，能解決這個(gè)問題。

四、為什么

上面解釋了指針如何運(yùn)行超過緩沖區(qū)的末尾，但是問題內(nèi)部為什么沒有顯示。畢竟，這個(gè)代碼在生產(chǎn)環(huán)境上已經(jīng)穩(wěn)定很多年了。

回到上面定義的script_consume_attr:

script_consume_attr := ((unquoted_attr_char)* :>> (space|'/'|'>')) 
>{ ddctx("script consume_attr"); } 
@{ fhold; fgoto script_tag_parse; } 
$lerr{ dd("script consume_attr failed"); 
       fgoto script_consume_attr; }; 

當(dāng)解析器解析超過字符范圍時(shí)會(huì)發(fā)生什么，當(dāng)前被解析的緩沖區(qū)是否是最后一個(gè)緩沖區(qū)是不同的。如果它不是最后一個(gè)緩沖區(qū)，那么沒必要使用$lerr，因?yàn)榻馕銎鞑恢朗欠駮?huì)發(fā)生錯(cuò)誤，因?yàn)槭Ｓ嗟膶傩钥赡茉谙乱粋€(gè)緩沖區(qū)中。

但是如果這是最后一個(gè)緩沖區(qū)，那么$lerr被執(zhí)行。下面是代碼末尾如何跳過了文件末尾且運(yùn)行內(nèi)存。

解析函數(shù)的入口點(diǎn)是ngx_http_email_parse_email(名字是古老的，它不止做了郵件解析的事)。

ngx_int_t ngx_http_email_parse_email(ngx_http_request_t *r, ngx_http_email_ctx_t *ctx) { 
    u_char  *p = ctx->pos; 
    u_char  *pe = ctx->buf->last; 
    u_char  *eof = ctx->buf->last_buf ? pe : NULL; 

你能看到p指向緩沖區(qū)的第一個(gè)字符，pe是緩沖區(qū)后的字符，且pe設(shè)置為eof。如果這是這個(gè)鏈中的最后一個(gè)緩沖區(qū)(有boolean last_buf表示)，否者為NULL。

當(dāng)老的和新的解析器在請(qǐng)求處理時(shí)同時(shí)存在，這類緩沖區(qū)將傳給上面的函數(shù)。

(gdb) p *in->buf 
$8 = { 
  pos = 0x558a2f58be30 "<script type=\"", 
  last = 0x558a2f58be3e "", 
  [...] 
  last_buf = 1, 
  [...] 
} 

上面是數(shù)據(jù)，last_buf是1。當(dāng)新的解析器不存在時(shí)，最后一個(gè)緩沖區(qū)包含的數(shù)據(jù)如下：

(gdb) p *in->buf 
$6 = { 
  pos = 0x558a238e94f7 "<script type=\"", 
  last = 0x558a238e9504 "", 
  [...] 
  last_buf = 0, 
  [...] 
} 

最后的空緩沖區(qū)(pos和last都是NULL且last_buf=1)接著那個(gè)緩沖區(qū)，但是如果緩沖區(qū)是空的，ngx_http_email_parse_email不會(huì)被調(diào)用。

因此，只有當(dāng)老的解析器存在是，最后一個(gè)緩沖區(qū)包含的數(shù)據(jù)才有l(wèi)ast_buf是0。這意味著eof將是NULL?，F(xiàn)在當(dāng)試圖在緩沖區(qū)末尾處理一個(gè)不完整的script_consume_attr。$ lerr將不會(huì)被執(zhí)行，因?yàn)榻馕銎飨嘈?因?yàn)閘ast_buf)可能有更多的數(shù)據(jù)來了。

當(dāng)兩個(gè)解析器都存在時(shí)，情況是不同的。 last_buf為1，eof設(shè)置為pe，$ lerr代碼運(yùn)行。下面是生成的代碼：

/* #line 877 "ngx_http_email_filter_parser.rl" */ 
{ dd("script consume_attr failed"); 
              {goto st1266;} } 
     goto st0; 
[...] 
st1266: 
    if ( ++p == pe ) 
        goto _test_eof1266; 

解析器解析完字符，而試圖執(zhí)行script_consume_attr， p將是pe。因?yàn)闆]有fhold(這將做p--)，當(dāng)代碼跳轉(zhuǎn)到st1266， p增加將超過pe。

然后不會(huì)跳轉(zhuǎn)到_test_eof1266(在這將執(zhí)行EOF校驗(yàn))，并且將超過緩沖區(qū)末尾，試圖解析HTML文檔。

因此，bug潛伏了多年，直到在NGINX過濾器模塊之間傳遞的緩沖區(qū)的內(nèi)部風(fēng)水隨著cf-html的引入而改變。

五、繼續(xù)尋找bug

在1960和1970年代，IBM的研究展示了bug集中在易錯(cuò)模塊中。因?yàn)槲覀冊(cè)赗agel生成的代碼中找到了一個(gè)討厭的指針溢出，所以將謹(jǐn)慎的去查找其他的bug。

信息安全團(tuán)隊(duì)的一部分人開始模糊測(cè)試生成的代碼，來查找潛在的指針溢出。另一個(gè)團(tuán)隊(duì)使用惡意構(gòu)造的web網(wǎng)頁構(gòu)建測(cè)試用例。軟件工程師團(tuán)隊(duì)開始手動(dòng)排查代碼問題。

決定在生成的代碼中為每個(gè)訪問的指針顯式添加校驗(yàn)，并且計(jì)入任何發(fā)生的錯(cuò)誤。生成的錯(cuò)誤被反饋到我們的全局錯(cuò)誤記錄基礎(chǔ)結(jié)構(gòu)，用于分析。

#define SAFE_CHAR ({\ 
    if (!__builtin_expect(p < pe, 1)) {\ 
        ngx_log_error(NGX_LOG_CRIT, r->connection->log, 0, "email filter tried to access char past EOF");\ 
        RESET();\ 
        output_flat_saved(r, ctx);\ 
        BUF_STATE(output);\ 
        return NGX_ERROR;\ 
    }\ 
    *p;\ 
}) 

看到日志如下：

2017/02/19 13:47:34 [crit] 27558#0: *2 email filter tried to access char past EOF while sending response to client, client: 127.0.0.1, server: localhost, request: "GET /malformed-test.html HTTP/1.1” 

每行日志表示一個(gè)HTTP請(qǐng)求，可能有泄漏的內(nèi)存。通過記錄問題發(fā)生的頻率，我們希望得到在錯(cuò)誤存在時(shí)HTTP請(qǐng)求泄漏內(nèi)存的次數(shù)的統(tǒng)計(jì)。

為了針對(duì)內(nèi)存泄漏，下面的東西必須正確：

• 最后一個(gè)緩沖區(qū)包含的數(shù)據(jù)必須以以惡意格式的腳本或者img標(biāo)簽結(jié)束
• 緩沖區(qū)必須小于4K長(zhǎng)度(否則Nginx可能崩潰)
• 用戶必須開啟郵件混淆(因?yàn)樗瑫r(shí)使用新舊解析器)。

…或者自動(dòng)HTTPs重寫/服務(wù)端排除(使用了新解析器)組合另一個(gè)使用老的解析器的功能。…并且服務(wù)端排除只有在客戶端IP具有較差的信譽(yù)(即它對(duì)大多數(shù)訪問者不起作用)時(shí)才執(zhí)行。

那就解釋了為什么緩沖區(qū)溢出導(dǎo)致了內(nèi)存泄漏的發(fā)生的情況如此少。

此外，郵件模糊功能(使用兩個(gè)解析器，并會(huì)使錯(cuò)誤發(fā)生在大多數(shù)Cloudflare網(wǎng)站上)僅在2月13日(Tavis報(bào)告的前四天)啟用。

涉及的三個(gè)功能按如下順序推出。內(nèi)存可能泄漏的最早的日期是2016-09-22。

• 2016-09-22 Automatic HTTP Rewrites 啟用
• 2017-01-30 Server-Side Excludes 整合新的解析器
• 2017-02-13 Email Obfuscation 部分整合新的解析器
• 2017-02-18 Google 報(bào)告問題給Cloudflare且泄漏結(jié)束

最大的潛在威脅發(fā)生在2月13號(hào)開始的4天內(nèi)，因?yàn)樽詣?dòng)HTTP重寫沒有被廣泛使用，服務(wù)端排除只對(duì)惡意的IP地址才有效。

六、Bug的內(nèi)部影響

Cloudflare在邊界機(jī)器上面運(yùn)行了多個(gè)獨(dú)立的進(jìn)程，且提供了進(jìn)程和內(nèi)存隔離。內(nèi)存泄漏來自與一個(gè)基于Nginx的進(jìn)程(處理HTTP)。它有一個(gè)獨(dú)立的進(jìn)程堆處理SSL，圖片壓縮和緩存，意味著我們很很快判斷我們客戶的SSL私鑰沒有泄漏。

然而，內(nèi)存空間的泄漏包含了敏感信息。泄漏的信息中明顯的一個(gè)是用于在Cloudflare機(jī)器之間安全連接的私鑰。

當(dāng)處理客戶網(wǎng)站HTTP請(qǐng)求時(shí)，我們的邊界機(jī)器在機(jī)架內(nèi)，在數(shù)據(jù)中心內(nèi)，以及用于記錄，緩存和從源Web服務(wù)器檢索網(wǎng)頁的數(shù)據(jù)中心之間相互通信。

為了響應(yīng)對(duì)互聯(lián)網(wǎng)公司的監(jiān)控活動(dòng)的高度關(guān)注，我們決定在2013年加密Cloudflare機(jī)器之間的所有連接，以防止這樣的攻擊，即使機(jī)器坐在同一機(jī)架。

泄漏的私鑰是用于此機(jī)器加密的私鑰。在Cloudflare內(nèi)部還有少量的密鑰用于認(rèn)證。

七、外部影響和緩存清除

更關(guān)心的事實(shí)是大量的Cloudflare客戶的HTTP請(qǐng)求存在于轉(zhuǎn)儲(chǔ)的內(nèi)存中。這意味著隱私信息泄露了。

這包括HTTP頭，POST數(shù)據(jù)(可能包含密碼)，API調(diào)用的JSON，URI參數(shù)，Cookie和用于身份認(rèn)證的其他敏感信息(例如API密鑰和OAuth令牌)。

因?yàn)镃loudflare運(yùn)行大型共享基礎(chǔ)架構(gòu)，因此對(duì)易受此問題影響的Cloudflare網(wǎng)站的HTTP請(qǐng)求可能會(huì)泄露不相關(guān)的其他Cloudflare站點(diǎn)的信息。

另一個(gè)問題是，Google(和其他搜索引擎)通過其正常的抓取和緩存過程緩存了一些泄漏的內(nèi)存。我們想要確保在公開披露問題之前從搜索引擎緩存中清除這些內(nèi)存，以便第三方無法搜索敏感信息。

我們傾向是盡快得到錯(cuò)誤的消息，但我們認(rèn)為我們有責(zé)任確保搜索引擎緩存在公開宣布之前被擦除。

信息安全團(tuán)隊(duì)努力在搜索引擎緩存中識(shí)別已泄漏內(nèi)存并清除內(nèi)存的URI。在Google，Yahoo，Bing和其他人的幫助下，我們發(fā)現(xiàn)了770個(gè)已被緩存且包含泄漏內(nèi)存的獨(dú)特的URI。770個(gè)獨(dú)特的URI涵蓋161個(gè)唯一域。泄漏的內(nèi)存已經(jīng)在搜索引擎的幫助下清除。

我們還進(jìn)行其他搜索，尋找在像Pastebin這樣的網(wǎng)站上可能泄漏的信息，且沒有找到任何東西。

八、一些課題

新的HTML解析器的工程師一直擔(dān)心影響我們的服務(wù)，他們花了幾個(gè)小時(shí)來驗(yàn)證它不包含安全問題。

不幸的是，這是一個(gè)古老的軟件且包含一個(gè)潛在的安全問題，而這個(gè)問題只出現(xiàn)于我們?cè)谶w移拋棄它的過程。我們的內(nèi)部信息安全團(tuán)隊(duì)現(xiàn)在正在進(jìn)行一個(gè)項(xiàng)目，以模糊測(cè)試舊軟件的方式尋找潛在的其他安全問題。

九、時(shí)間點(diǎn)細(xì)節(jié)

我們非常感謝Google的同事就此問題與我們聯(lián)系，并通過其解決方案與我們密切合作。所有這些都沒有任何報(bào)告,表明外界的各方已經(jīng)確定了問題或利用它。

所有時(shí)間均為UTC時(shí)間。

• 2017-02-18 0011 來自Tavis Ormandy的推特尋求Cloudflare的聯(lián)系方式
• 2017-02-18 0032 Cloudflare 收到來自谷歌的bug細(xì)節(jié)
• 2017-02-18 0040 多個(gè)團(tuán)隊(duì)匯集在San Francisco
• 2017-02-18 0119 全球范圍內(nèi)關(guān)閉郵件混淆功能
• 2017-02-18 0122 London團(tuán)隊(duì)加入
• 2017-02-18 0424 自動(dòng)HTTPs重寫功能關(guān)閉
• 2017-02-18 0722 實(shí)現(xiàn)針對(duì)cf-html解析器的關(guān)閉開關(guān)，并全球部署
• 2017-02-20 2159 SAFE_CHAR 修復(fù)部署
• 2017-02-21 1803 自動(dòng)HTTPs重寫，服務(wù)端排除和郵件混淆重啟功能