案例分享：一封郵件如何影響整個(gè)郵件服務(wù)的解析

作者：陳峻編譯 2019-04-25 09:00:00

本文通過作者的親身經(jīng)歷，分析了Node.js類電子郵件解析器的DoS漏洞，并提出九項(xiàng)有針對(duì)性的最佳實(shí)踐。

【51CTO.com快譯】最近業(yè)界發(fā)現(xiàn)并公布了五大流行Node.js類電子郵件解析器的如下疑似漏洞，這些漏洞都屬于隱蔽漸進(jìn)式的拒絕服務(wù)(DoS)類型。

u Haraka的漏洞-https://snyk.io/vuln/search?q=haraka&type=npm?utm_source=dzone&utm_medium=content&utm_campaign=content_promo&utm_content=email_exploit
u mailparser的漏洞--https://snyk.io/vuln/npm:emailjs-mime-parser?utm_source=dzone&utm_medium=content&utm_campaign=content_promo&utm_content=email_exploit
u emailjs-mime-parser的漏洞--https://snyk.io/vuln/npm:mailparser-mit?utm_source=dzone&utm_medium=content&utm_campaign=content_promo&utm_content=email_exploit
u mailsplit的漏洞--https://snyk.io/vuln/npm:mailsplit?utm_source=dzone&utm_medium=content&utm_campaign=content_promo&utm_content=email_exploit
u mailparser-mit的漏洞--https://snyk.io/vuln/npm:emailjs-mime-parser?utm_source=dzone&utm_medium=content&utm_campaign=content_promo&utm_content=email_exploit

為了利用這些漏洞，可以通過在電子郵件中附上幾百萬個(gè)空的附件，來繞過典型的郵件大小限制(通常為20 MB或更少)。因此，當(dāng)此類電子郵件被發(fā)送到脆弱的郵件服務(wù)器上時(shí)，由于附件數(shù)量過于龐大，所以它會(huì)讓Node.js的事件循環(huán)(event loop)停滯幾秒鐘。

[[263460]]

同時(shí)，由于為每個(gè)附件都創(chuàng)建了一個(gè)內(nèi)部對(duì)象，因此內(nèi)存的使用量會(huì)馬上“爆”到2 GB或者更多，從而讓整個(gè)服務(wù)器因?yàn)閮?nèi)存的不足而崩潰。

那么，您真的確信自己的Node.js服務(wù)器能安全地解析電子郵件嗎?下面，我將通過自己的親身經(jīng)歷來和大家一起分析并檢查電子郵件的解析器。

在開始深入探討之前，讓我們先來欣賞一下由XKCD(由Randall Munroe創(chuàng)作的著名的網(wǎng)絡(luò)漫畫。請(qǐng)參見https://xkcd.com/1873/)帶來的“強(qiáng)迫癥”漫畫。

拒絕服務(wù)工具有那么簡(jiǎn)單嗎?

由于依賴項(xiàng)的普及，上述漏洞一旦被利用，就會(huì)波及到數(shù)千個(gè)系統(tǒng)。例如：mailparser庫(請(qǐng)參見https://www.npmjs.com/package/mailparser)每月的下載量就多達(dá)249,400次，并且目前已被214個(gè)其他項(xiàng)目(包括Sendgrid https://www.npmjs.com/package/@sendgrid/inbound-mail-parser)用作依賴項(xiàng)。而Haraka(請(qǐng)參見https://www.npmjs.com/package/Haraka)則是另一個(gè)影響深遠(yuǎn)的庫，它正在被Craigslist(請(qǐng)參見https://www.craigslist.org/about/thanks)、Fort Anti-Spam(請(qǐng)參見https://www.fortantispam.com/)和ThreatWave(請(qǐng)參見https://haraka.github.io/users.html)所使用著。

通常，您大可不必請(qǐng)來Cloudflare(譯者注：一家提供網(wǎng)站安全管理的公司)的專業(yè)服務(wù)與幫助，您完全可以自行通過添加一行簡(jiǎn)單的代碼，來修復(fù)該問題。例如，您可以通過計(jì)算附件(包括那些文本部分)的數(shù)量，來驗(yàn)證用戶數(shù)據(jù)的合法性。例如，您可以設(shè)定為：如果附件的數(shù)量超過1000，則采取丟棄之類的反應(yīng)動(dòng)作。

不過，此類修復(fù)只是一種治標(biāo)不治本的被動(dòng)防御，它在上述五種郵件解析器中的實(shí)現(xiàn)方式不盡相同，也不盡完全奏效。因此，我們必須通過如下的改進(jìn)方式，來真正找到并修補(bǔ)此類漏洞。

想象一下，您正在編寫一個(gè)郵件解析器......

作為一名開發(fā)者，您應(yīng)該知道有多少份RFC需要閱讀和掌握，也應(yīng)該知道需要編寫多少種測(cè)試，來確保自己的程序能夠符合RFC的相關(guān)規(guī)定。同時(shí)，您也一定聽過軟件行業(yè)內(nèi)的那句名言：“先讓它運(yùn)行起來，再讓它運(yùn)行得更快。”不過，這一套理論對(duì)于電子郵件解析器來說卻不那么奏效。就算完成了郵件解析器的編寫，您也無法僅僅通過粗略的背板計(jì)算(back-of-the-envelope calculation，請(qǐng)參見https://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html)，來估算出：在自己的應(yīng)用中，應(yīng)當(dāng)分配多少數(shù)量的內(nèi)存給一個(gè)包含了multipart的對(duì)象。而且，通過復(fù)雜的分析，您還可能發(fā)現(xiàn)如下問題：

不止需要測(cè)試內(nèi)存的用量，您還可能需要測(cè)量CPU使用率。
您可能無法對(duì)那些典型的內(nèi)存占用量，開展基準(zhǔn)化的測(cè)試。
由于最終的SMTP應(yīng)用環(huán)境存在著不定性，因此就算90%的電子郵件確實(shí)為垃圾郵件，您也無法去啟用任何一種快速的解析路徑。
您完全可以避免在解析器中執(zhí)行太多、太嚴(yán)格的策略決策(policy decision)。
您的用戶可能并不買賬，您對(duì)每封郵件采取的大附件數(shù)量的限制。
由于不是郵件服務(wù)器的管理員，您可能會(huì)更愿意在SMTP的事務(wù)處理期間，完成了所有內(nèi)容的解析之后，讓用戶自行去判斷和拒收某些郵件。

想象一下，您正在運(yùn)行一個(gè)電子郵件服務(wù)器......

鑒于上述情況，您需要做的事就是：設(shè)置郵件的大小限制。顯然，郵件越大，它被服務(wù)器接收的可能性就越小。因此，為了將解析時(shí)間控制在合理范圍內(nèi)，您可以將單封郵件的體積上限限制為20MB。籍此，您就可以放心地使用那些“經(jīng)過實(shí)戰(zhàn)考驗(yàn)”的、時(shí)下流行的郵件解析器。

為了簡(jiǎn)化郵件解析器的復(fù)雜性，您可以直接將處置20MB電子郵件時(shí)的CPU使用率作為參考基線準(zhǔn)，以保證自己的服務(wù)器能夠每秒處理數(shù)千封郵件。因此，假設(shè)服務(wù)器處理相同大小郵件的時(shí)間就是恒定的，那么您只需要8GB的內(nèi)存，便可足夠應(yīng)對(duì)每秒200封且大小為20MB的郵件并發(fā)量了。有了這樣的簡(jiǎn)化場(chǎng)景，您后續(xù)只需要考慮帶有0字節(jié)的附件，即空文件的安全危害即可。相關(guān)概念請(qǐng)參見：https://en.wikipedia.org/wiki/Zip_bomb。下面是一個(gè)簡(jiǎn)單的范例：

MIME-Version: 1.0 
From:  
To:  
Subject: MIME Multipart Attack 
Date: Sat, 30 Jun 2018 15:51:58 +0000 
Message-ID:  
Content-Type: multipart/mixed; boundary="0" 
--0 
Content-Type: text/plain; charset=UTF-8 
Content-Transfer-Encoding: quoted-printable 
--0 
--0 
--0 
--0 
--0 
--0 
--0 
--0 [× 4 million]

如何發(fā)現(xiàn)此類漏洞?

回到開始提到的案例，我曾經(jīng)遇到過：由于一個(gè)奇怪的入棧郵件，突然導(dǎo)致了V8(一種JavaScript引擎)的垃圾收集器一次性地阻止了Node.js的事件循環(huán)長(zhǎng)達(dá)幾十秒。我為此花費(fèi)了兩天的時(shí)間，每隔幾分鐘就去重置feature-flags，以減少郵件隊(duì)列的負(fù)荷。在Vyacheslav Egorov(請(qǐng)參見https://github.com/mraleph)的幫助下，我注釋掉了V8的CollectAllAvailableGarbage函數(shù)(請(qǐng)參見https://github.com/v8/v8/blob/master/src/heap/heap.cc#L1237)。該函數(shù)的內(nèi)部工作原理是：對(duì)那些巨大的(幾個(gè)GB大小)堆棧隨機(jī)進(jìn)行七次收集。由此，我所吸取到的教訓(xùn)是：應(yīng)當(dāng)謹(jǐn)慎地對(duì)堆棧進(jìn)行對(duì)象分配，進(jìn)而避免對(duì)事件循環(huán)的阻斷。

從去年年初開始，我不斷在開源社區(qū)--https://github.com/ronomon/mime上編寫并更新自己的郵件解析器。我的目標(biāo)是：希望新的版本能夠具有更快的解析速度、更少的資源分配數(shù)、能夠在原始的緩沖區(qū)上運(yùn)行、以及對(duì)RFC具有100%測(cè)試覆蓋率(包括模糊測(cè)試，fuzz tests)。

在此過程中，我進(jìn)一步了解到：策略決策會(huì)比郵件服務(wù)器本身更有利于郵件的解析;同時(shí)，郵件的解析也會(huì)反過來促進(jìn)策略的決策。此處的策略決策包括：拒絕明顯的惡意代碼，拒絕各種損壞的、或被截?cái)嗟腂ase64、以及Quoted-Printable之類的字符編碼，拒絕重復(fù)性的關(guān)鍵標(biāo)題(請(qǐng)參見https://noxxi.de/research/content-transfer-encoding.html)，限制multipart的數(shù)量，以及限制由于對(duì)multipart邊界的誤報(bào)而引起的回溯。

今年初，我與《避免阻斷Node.js事件循環(huán)的完全指南》(an excellent guide to not blocking the Node.js event loop，請(qǐng)參見https://nodejs.org/en/docs/guides/dont-block-the-event-loop/)一文的作者--Jamie Davis取得了聯(lián)系。Jamie在文中所討論的如何抵御事件循環(huán)風(fēng)險(xiǎn)，正是我在本文中提及的，針對(duì)郵件解析器的multipart風(fēng)險(xiǎn)。

九點(diǎn)改進(jìn)建議

在此，我為大家列出了針對(duì)此類問題的九項(xiàng)值得嘗試的實(shí)踐：

1. DoS對(duì)于資源稀缺的系統(tǒng)更容易產(chǎn)生效果。作為知識(shí)的積累，您可以通過《mechanical sympathy》(https://mechanical-sympathy.blogspot.com/2011/07/why-mechanical-sympathy.html)一文，來了解底層硬件是如何運(yùn)作的，以及如何通過編程，實(shí)現(xiàn)與底層硬件的良好協(xié)作。由于解析的算法既會(huì)涉及到CPU的使用，又會(huì)涉及到內(nèi)存的分配，因此我們需要事先合理地配置好硬件資源。如果您的代碼能夠有效地使用CPU、內(nèi)存、磁盤、及網(wǎng)絡(luò)的話，那么您可能就不太會(huì)碰到資源匱乏的問題。當(dāng)然，您仍需要對(duì)所有的系統(tǒng)資源，進(jìn)行合理的使用限制。

2. 在設(shè)計(jì)之初，就從不同的資源維度進(jìn)行粗略的背板計(jì)算。此法能夠盡早地暴露并發(fā)現(xiàn)設(shè)計(jì)中的缺陷，進(jìn)而避免產(chǎn)生那些“不可能”的解析。由于系統(tǒng)的性能和安全性通常很難通過后期的優(yōu)化而有所改進(jìn)，因此它們需要在初期就被規(guī)劃好，而不要等到用戶使用量上去了，才“亡羊補(bǔ)牢”。

3. 平衡所有維度上的資源使用情況。不要出現(xiàn)：您雖然尚有足夠的CPU去滿足吞吐量的需求，但早已耗盡了內(nèi)存的情況。因此，您同樣需要通過粗略的背面計(jì)算，來保持各類資源的使用占比，以避免產(chǎn)生各種設(shè)計(jì)中的潛在瓶頸。

4. 記住：在運(yùn)行事件循環(huán)時(shí)，大多數(shù)性能問題都源自拒絕服務(wù)式的等待。因此，如果有用戶報(bào)告性能問題，那么您首要檢查的應(yīng)該就是安全方面的風(fēng)險(xiǎn)可能性。

5. 驗(yàn)證所有用戶的入棧數(shù)據(jù)，不僅要考察單位時(shí)間的數(shù)據(jù)量，還應(yīng)當(dāng)檢查一段時(shí)間的總量。某些風(fēng)險(xiǎn)往往會(huì)以潛移默化的方式，對(duì)您的郵件系統(tǒng)進(jìn)行逐步滲透，然后產(chǎn)生倍數(shù)效應(yīng)，并最終接管您的系統(tǒng)。

6. 注意模塊邊界之間的“空白地帶”。不要依賴其他的開發(fā)伙伴去幫助您彌補(bǔ)這些不足之處。為了避免策略決策上的缺陷，您應(yīng)當(dāng)更好地了解代碼間的依賴關(guān)系。

7. 從整體的安全角度出發(fā)，制定嚴(yán)格的過濾策略，對(duì)于不確定是否“健康”的郵件，系統(tǒng)應(yīng)當(dāng)堅(jiān)決“拒之千里之外”。

8. 不要只是從開發(fā)人員的角度去檢查自己的代碼，而需要從惡意擊者的角度出發(fā)，考慮他們會(huì)如何利用那些郵件解析中的代碼漏洞。在程序發(fā)布之前，請(qǐng)?jiān)诿總€(gè)模塊中至少仔細(xì)地檢查并修復(fù)三個(gè)漏洞。

9. 編寫簡(jiǎn)單的模糊測(cè)試用例(請(qǐng)參見https://en.wikipedia.org/wiki/Fuzzing)，以隨機(jī)生成各種有效的和無效的參數(shù)。針對(duì)某個(gè)函數(shù)相對(duì)其他函數(shù)的返回值，請(qǐng)測(cè)試其有效性、正確性、以及各種無效的異常輸出。您可以根據(jù)Linus極端法則(請(qǐng)參見https://en.wikipedia.org/wiki/Linus%27s_Law)，運(yùn)行具有數(shù)百萬個(gè)參數(shù)組合的函數(shù)模糊測(cè)試。

私有與公共披露時(shí)間表

該漏洞已于2018年4月23日向受影響模塊的所有者進(jìn)行了披露。不過，就在90天的公開披露截止日期到期之前，該所有者以某種理由推遲了對(duì)它的公開披露。此后，通過聯(lián)系與之相關(guān)的依賴項(xiàng)模塊(主要是在GitHub上)，該漏洞已于2018年6月25日得到了全面公開與披露。

另外，有關(guān)這五大Node.js類郵件解析器的DoS漏洞介紹和具體信息，請(qǐng)參見下表：

1. haraka (versions < 2.8.19)

https://snyk.io/vuln/npm:haraka:20180625