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

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

[[263460]]

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

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

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

拒絕服務工具有那么簡單嗎?

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

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

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

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

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

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

想象一下，您正在運行一個電子郵件服務器......

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

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

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

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

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

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

九點改進建議

在此，我為大家列出了針對此類問題的九項值得嘗試的實踐：

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

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

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

4. 記?。涸谶\行事件循環(huán)時，大多數(shù)性能問題都源自拒絕服務式的等待。因此，如果有用戶報告性能問題，那么您首要檢查的應該就是安全方面的風險可能性。

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

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

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

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

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

私有與公共披露時間表

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

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

1. haraka (versions < 2.8.19)

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

• April 23rd, 2018 - Initial private disclosure to package owner
• April 24th, 2018 - Initial response from package owner
• June 15th, 2018 - Vulnerability fixed but not yet published to npm
• June 25th, 2018 - Public disclosure
• June 27th, 2018 - Version 2.8.19 published with fix

2. mailparser (ALL versions)

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

• April 23rd, 2018 - Initial private disclosure to package owner
• April 24th, 2018 - Initial response from package owner
• June 25th, 2018 - Public disclosure

3. emailjs-mime-parser (ALL versions)

https://snyk.io/vuln/npm:emailjs-mime-parser:20180625

• April 23rd, 2018 - Initial private disclosure to package owner
• April 24th, 2018 - Initial response from package owner
• June 25th, 2018 - Public disclosure

4. mailsplit (versions < 4.2.1)

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

• April 23rd, 2018 - Initial private disclosure to package owner
• April 24th, 2018 - Initial response from package owner
• June 25th, 2018 - Public disclosure
• July 23rd, 2018 - Version 4.2.1 published with fix

5. mailparser-mit (ALL versions)

https://snyk.io/vuln/npm:mailparser-mit:20180625

• April 23rd, 2018 - Initial private disclosure to package owner
• April 24th, 2018 - Initial response from package owner
• June 25th, 2018 - Public disclosure

原文標題：How to Crash an Email Server With a Single Email，作者：Liran Tal

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】