Cloudflare解析器bug導致內存泄漏事件報告
一、前言
上星期五，來自谷歌Project Zero組織的Tavis Ormandy聯系Cloudflare，報告了我們的邊界服務器的一個安全問題。他看到經過Cloudflare的一些HTTP請求返回了崩潰的網頁。
它出現在一些不尋常的情況下，在下面我將詳細介紹，我們的邊界服務器運行時緩沖區越界了，并返回了隱私信息，如 HTTP cookies，認證令牌，HTTP POST體和其他敏感數據的內存。并且有些數據會被搜索引擎緩存。
為了避免懷疑，Cloudflare客戶的SSL私鑰沒有泄漏。Cloudflare總是通過一個隔離的Nginx實例來結束SLL連接，因此不受這個bug影響。
我們快速的確認了這個問題，并關閉了3個Cloudflare功能(郵件混淆，服務端排除和自動HTTPs重寫)，這些都用來了相同的HTML解析器鏈，會導致泄漏。這樣在一個HTTP響應中就不會有內存返回了。
因為這個bug的嚴重性，來自San Francisco和 London的軟件工程師、信息安全和操作的交叉功能團隊充分了解了潛在的原因，為了降低內存泄漏的影響，和谷歌和其他搜索引擎團隊一起將緩存的HTTP響應移除了。
擁有一個全球化的團隊，每12小時為間隔，每天24小時交替解決這個問題。團隊持續的努力確保了問題的圓滿解決。作為服務的一個優勢是這個bug從報告到解決，花了幾分鐘到幾小時，而不是幾個月。針對這樣的bug部署修復方案的工業標準通常是3個月;我們在小于7個小時就圓滿解決，47分鐘內就緩解了bug。
這個bug是嚴重的，因為泄漏的內存包含了隱私信息，并且還會被搜索引擎緩存。我們還沒有發現這個bug的漏洞利用或者它們存在的報告。
影響最大的時期是2月13日到2月18號，通過Cloudflare的每3,300,000個HTTP請求中約有1個可能導致內存泄漏(約為請求的0.00003%)。
我們感謝它由世界頂級安全研究團隊發現并報告給我們。
本文很長，但是作為我們的傳統，我們傾向于對我們的服務出現的問題保持開放和技術上的詳細描述。
二、運行時解析并修改HTML
很多Cloudflare服務依賴通過我們的邊界服務器時解析和修改HTML頁面。例如，我們能通過修改HTML頁面來插入谷歌分析標簽，安全的重寫http://鏈接為https://，排除來自機器人的部分頁面，模糊電子郵件地址，啟用AMP等。
為了修改頁面，我們需要讀取并解析HTML以發現需要修改的元素。因為在Cloudflare的早期，我們已經使用了用Ragel編寫的解析器。一個獨立的.rl文件包含一個HTML解析器，被用來在Cloudflare平臺修改HTML。
大約一年前，我們認為Ragel解析器維護起來太復雜，并且我們開始寫一個新的解析器(cf-html)來替代它。這個解析器能正確處理HTML5，而且非常非常快且易維護。
我們首先將這個解析器用于自動HTTP重寫功能，并一直慢慢地遷移cf-html替換Ragel。
Cf-html和老的Ragel解析器都作為Nginx模塊實現，并編譯到我們的Nginx構建中。這個Nginx過濾模塊解析包含HTML響應的緩沖區(內存塊)，做出必要的修改，并將緩沖區傳遞給下一個過濾模塊。
這樣，引起內存泄漏的bug在我們的Ragel解析器中已存在多年，但是因為我們內部Nginx使用緩沖區的方式，并沒有內存泄漏。Cf-html巧妙的改變了緩沖去，導致在cf-html中不會有問題。
因為我們知道了這個bug是由激活cf-html引起的(但是之前我們知道為什么)，我們禁用了使用它的3個功能。Cloudflare每個功能都有一個相應的功能標志，我們稱之為全局殺手。我們在收到問題細節報告后的47分鐘時啟用了郵件混淆的全局殺手，并在3小時5分鐘后關閉了自動HTTP重寫。郵件混淆功能在2月13號已經修改了，并且是內存泄漏的原因，因此禁用它快速地阻止了幾乎所有的內存泄漏。
在幾秒內，這些功能在全球范圍內被禁用。我們確定沒有通過測試URI來泄漏內存，并且谷歌的二次校驗也一樣。
然后，我們發現了第三個功能(服務端排除)也有這個漏洞，但是沒有全局殺手開關(它非常老，在全局殺手之前實現)。我們為服務端排除實現了一個全局殺手，并全球部署補丁。從發現服務端排除是個問題到部署補丁只花了3個小時。然而，服務端排除很少使用，且只針對對惡意的IP地址才激活。
三、bug的根因
Ragel代碼轉化為C代碼，然后編譯。這個C代碼使用經典的C方法，指向HTML文檔的指針被解析，并且Ragel自身給用戶提供了針對這些指針大量的控制權。因為一個指針錯誤導致的bug的產生。
- /* generated code */
- if ( ++p == pe )
- goto _test_eof;
bug的根因是，使用等于運算符來校驗是否到達緩沖區的末端，并且指針能夠步過緩沖去末端。這是熟知的緩沖去溢出。使用>=代替==來做檢驗，將跳過緩沖區末端。這個等于校驗由Ragel自動生成，不是我們編寫的代碼。意味著我們沒有正確的使用Ragel。
我們編寫的Ragel代碼包含了一個bug，其能引起指針越界且給了等號校驗造成緩沖區溢出的能力。
下面是Ragel代碼的一段代碼，用來獲取HTML標簽中的一個屬性。第一行說的是它試圖找到更多以空格，正斜杠或>結尾的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; };
如果一個屬性格式良好，則Ragel解析器跳轉到@{}代碼塊。如果解析屬性失敗(就是我們今天討論的bug的開始)，那么到$lerr{}。
舉個例子，在實際情況下(細節如下)，如果web頁面以錯誤的HTML標簽結尾，如：
- <script type=
$lerr{ }塊將執行，并且緩沖去將溢出。這個例子中$lerr執行dd(“script consume_attr failed”);(這是個調試語句)，然后執行fgoto script_consume_attr;(轉移到script_consume_attr去解析下一個屬性)。
從我們的分析中看，這樣錯誤的標簽出現在大約0.06%的網站中。
如果你觀察仔細，你可能已經注意到@{ }也是一個fgoto，但是在它之前執行了fhold，并且$lerr{ }沒有。它沒有fhold導致了內存泄漏。
在內部，生成的C代碼有一個指針p，指向HTML文檔中正在檢測的字符。Fhold等價于p--，并且是必要的。因為當錯誤條件發生時，p將指向導致script_consume_attr失敗的字符。
并且它非常重要，因為如果這個錯誤條件發生在包含HTML文檔的緩沖區的末尾，則p將在文檔末端的后面(p將是pe+1)，且達到緩沖區末尾的校驗將失敗，p將在緩沖去外部運行。
添加一個fhold到錯誤處理函數中，能解決這個問題。
四、為什么
上面解釋了指針如何運行超過緩沖區的末尾，但是問題內部為什么沒有顯示。畢竟，這個代碼在生產環境上已經穩定很多年了。
回到上面定義的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; };
當解析器解析超過字符范圍時會發生什么，當前被解析的緩沖區是否是最后一個緩沖區是不同的。如果它不是最后一個緩沖區，那么沒必要使用$lerr，因為解析器不知道是否會發生錯誤，因為剩余的屬性可能在下一個緩沖區中。
但是如果這是最后一個緩沖區，那么$lerr被執行。下面是代碼末尾如何跳過了文件末尾且運行內存。
解析函數的入口點是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指向緩沖區的第一個字符，pe是緩沖區后的字符，且pe設置為eof。如果這是這個鏈中的最后一個緩沖區(有boolean last_buf表示)，否者為NULL。
當老的和新的解析器在請求處理時同時存在，這類緩沖區將傳給上面的函數。
- (gdb) p *in->buf
- $8 = {
- pos = 0x558a2f58be30 "<script type=\"",
- last = 0x558a2f58be3e "",
- [...]
- last_buf = 1,
- [...]
- }
上面是數據，last_buf是1。當新的解析器不存在時，最后一個緩沖區包含的數據如下：
- (gdb) p *in->buf
- $6 = {
- pos = 0x558a238e94f7 "<script type=\"",
- last = 0x558a238e9504 "",
- [...]
- last_buf = 0,
- [...]
- }
最后的空緩沖區(pos和last都是NULL且last_buf=1)接著那個緩沖區，但是如果緩沖區是空的，ngx_http_email_parse_email不會被調用。
因此，只有當老的解析器存在是，最后一個緩沖區包含的數據才有last_buf是0。這意味著eof將是NULL。現在當試圖在緩沖區末尾處理一個不完整的script_consume_attr。$ lerr將不會被執行，因為解析器相信(因為last_buf)可能有更多的數據來了。
當兩個解析器都存在時，情況是不同的。 last_buf為1，eof設置為pe，$ lerr代碼運行。下面是生成的代碼：
- /* #line 877 "ngx_http_email_filter_parser.rl" */
- { dd("script consume_attr failed");
- {goto st1266;} }
- goto st0;
- [...]
- st1266:
- if ( ++p == pe )
- goto _test_eof1266;
解析器解析完字符，而試圖執行script_consume_attr， p將是pe。因為沒有fhold(這將做p--)，當代碼跳轉到st1266， p增加將超過pe。
然后不會跳轉到_test_eof1266(在這將執行EOF校驗)，并且將超過緩沖區末尾，試圖解析HTML文檔。
因此，bug潛伏了多年，直到在NGINX過濾器模塊之間傳遞的緩沖區的內部風水隨著cf-html的引入而改變。
五、繼續尋找bug
在1960和1970年代，IBM的研究展示了bug集中在易錯模塊中。因為我們在Ragel生成的代碼中找到了一個討厭的指針溢出，所以將謹慎的去查找其他的bug。
信息安全團隊的一部分人開始模糊測試生成的代碼，來查找潛在的指針溢出。另一個團隊使用惡意構造的web網頁構建測試用例。軟件工程師團隊開始手動排查代碼問題。
決定在生成的代碼中為每個訪問的指針顯式添加校驗，并且計入任何發生的錯誤。生成的錯誤被反饋到我們的全局錯誤記錄基礎結構，用于分析。
- #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”
每行日志表示一個HTTP請求，可能有泄漏的內存。通過記錄問題發生的頻率，我們希望得到在錯誤存在時HTTP請求泄漏內存的次數的統計。
為了針對內存泄漏，下面的東西必須正確：
- 最后一個緩沖區包含的數據必須以以惡意格式的腳本或者img標簽結束
- 緩沖區必須小于4K長度(否則Nginx可能崩潰)
- 用戶必須開啟郵件混淆(因為她同時使用新舊解析器)。
…或者自動HTTPs重寫/服務端排除(使用了新解析器)組合另一個使用老的解析器的功能。…并且服務端排除只有在客戶端IP具有較差的信譽(即它對大多數訪問者不起作用)時才執行。
那就解釋了為什么緩沖區溢出導致了內存泄漏的發生的情況如此少。
此外，郵件模糊功能(使用兩個解析器，并會使錯誤發生在大多數Cloudflare網站上)僅在2月13日(Tavis報告的前四天)啟用。
涉及的三個功能按如下順序推出。內存可能泄漏的最早的日期是2016-09-22。
- 2016-09-22 Automatic HTTP Rewrites 啟用
- 2017-01-30 Server-Side Excludes 整合新的解析器
- 2017-02-13 Email Obfuscation 部分整合新的解析器
- 2017-02-18 Google 報告問題給Cloudflare且泄漏結束
最大的潛在威脅發生在2月13號開始的4天內，因為自動HTTP重寫沒有被廣泛使用，服務端排除只對惡意的IP地址才有效。
六、Bug的內部影響
Cloudflare在邊界機器上面運行了多個獨立的進程，且提供了進程和內存隔離。內存泄漏來自與一個基于Nginx的進程(處理HTTP)。它有一個獨立的進程堆處理SSL，圖片壓縮和緩存，意味著我們很很快判斷我們客戶的SSL私鑰沒有泄漏。
然而，內存空間的泄漏包含了敏感信息。泄漏的信息中明顯的一個是用于在Cloudflare機器之間安全連接的私鑰。
當處理客戶網站HTTP請求時，我們的邊界機器在機架內，在數據中心內，以及用于記錄，緩存和從源Web服務器檢索網頁的數據中心之間相互通信。
為了響應對互聯網公司的監控活動的高度關注，我們決定在2013年加密Cloudflare機器之間的所有連接，以防止這樣的攻擊，即使機器坐在同一機架。
泄漏的私鑰是用于此機器加密的私鑰。在Cloudflare內部還有少量的密鑰用于認證。
七、外部影響和緩存清除
更關心的事實是大量的Cloudflare客戶的HTTP請求存在于轉儲的內存中。這意味著隱私信息泄露了。
這包括HTTP頭，POST數據(可能包含密碼)，API調用的JSON，URI參數，Cookie和用于身份認證的其他敏感信息(例如API密鑰和OAuth令牌)。
因為Cloudflare運行大型共享基礎架構，因此對易受此問題影響的Cloudflare網站的HTTP請求可能會泄露不相關的其他Cloudflare站點的信息。
另一個問題是，Google(和其他搜索引擎)通過其正常的抓取和緩存過程緩存了一些泄漏的內存。我們想要確保在公開披露問題之前從搜索引擎緩存中清除這些內存，以便第三方無法搜索敏感信息。
我們傾向是盡快得到錯誤的消息，但我們認為我們有責任確保搜索引擎緩存在公開宣布之前被擦除。
信息安全團隊努力在搜索引擎緩存中識別已泄漏內存并清除內存的URI。在Google，Yahoo，Bing和其他人的幫助下，我們發現了770個已被緩存且包含泄漏內存的獨特的URI。770個獨特的URI涵蓋161個唯一域。泄漏的內存已經在搜索引擎的幫助下清除。
我們還進行其他搜索，尋找在像Pastebin這樣的網站上可能泄漏的信息，且沒有找到任何東西。
八、一些課題
新的HTML解析器的工程師一直擔心影響我們的服務，他們花了幾個小時來驗證它不包含安全問題。
不幸的是，這是一個古老的軟件且包含一個潛在的安全問題，而這個問題只出現于我們在遷移拋棄它的過程。我們的內部信息安全團隊現在正在進行一個項目，以模糊測試舊軟件的方式尋找潛在的其他安全問題。
九、時間點細節
我們非常感謝Google的同事就此問題與我們聯系，并通過其解決方案與我們密切合作。所有這些都沒有任何報告,表明外界的各方已經確定了問題或利用它。
所有時間均為UTC時間。
- 2017-02-18 0011 來自Tavis Ormandy的推特尋求Cloudflare的聯系方式
- 2017-02-18 0032 Cloudflare 收到來自谷歌的bug細節
- 2017-02-18 0040 多個團隊匯集在San Francisco
- 2017-02-18 0119 全球范圍內關閉郵件混淆功能
- 2017-02-18 0122 London團隊加入
- 2017-02-18 0424 自動HTTPs重寫功能關閉
- 2017-02-18 0722 實現針對cf-html解析器的關閉開關，并全球部署
- 2017-02-20 2159 SAFE_CHAR 修復部署
- 2017-02-21 1803 自動HTTPs重寫，服務端排除和郵件混淆重啟功能
