【51CTO.com快譯】最近業界發現并公布了五大流行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或更少)。因此，當此類電子郵件被發送到脆弱的郵件服務器上時，由于附件數量過于龐大，所以它會讓Node.js的事件循環(event loop)停滯幾秒鐘。

[[263460]]

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

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

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

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

由于依賴項的普及，上述漏洞一旦被利用，就會波及到數千個系統。例如：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(譯者注：一家提供網站安全管理的公司)的專業服務與幫助，您完全可以自行通過添加一行簡單的代碼，來修復該問題。例如，您可以通過計算附件(包括那些文本部分)的數量，來驗證用戶數據的合法性。例如，您可以設定為：如果附件的數量超過1000，則采取丟棄之類的反應動作。

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

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

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

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

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

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

為了簡化郵件解析器的復雜性，您可以直接將處置20MB電子郵件時的CPU使用率作為參考基線準，以保證自己的服務器能夠每秒處理數千封郵件。因此，假設服務器處理相同大小郵件的時間就是恒定的，那么您只需要8GB的內存，便可足夠應對每秒200封且大小為20MB的郵件并發量了。有了這樣的簡化場景，您后續只需要考慮帶有0字節的附件，即空文件的安全危害即可。相關概念請參見：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] 

如何發現此類漏洞?

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

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

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

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

九點改進建議

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

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

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

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

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

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

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

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

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

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

私有與公共披露時間表

該漏洞已于2018年4月23日向受影響模塊的所有者進行了披露。不過，就在90天的公開披露截止日期到期之前，該所有者以某種理由推遲了對它的公開披露。此后，通過聯系與之相關的依賴項模塊(主要是在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譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】