Http Options出血漏洞CVE-2017-9798 可導致內存泄漏 PoC已公開

周一，研究員Hanno B?ck發現HTTP Options存在出血漏洞CVE-2017-9798，如果網站管理員嘗試對無效的 HTTP 方法實施 "Limit" 指令, 則會導致出現漏洞利用的可能，攻擊得手後將導致伺服器敏感內存泄漏。目前Apache的開發商確認了這個漏洞，尚不清楚其它Web服務軟體是否存在這個問題。

如果您使用的是 HTTP 協議在日常的互聯網使用, 你通常只使用它的兩種方法: Get和Post。但是, HTTP 有許多其他方法, 所以我想您需要知道如何處理它們, 以及是否存在任何漏洞。

一個 HTTP 方法稱為Options。它只允許詢問伺服器，它能支持的其他 HTTP 方法。伺服器用 "Allow" 頭來應答, 並給我們一個列表，列表項目用逗號來分隔。

Http Options出血漏洞CVE-2017-9798

對 Alexa 前100萬的網站進行了掃描，發現了一些奇怪的事情，大量的伺服器發送了一個 "Allow" 頭, 看起來像損壞的數據。一些例子

Allow: ,GET,,,POST,OPTIONS,HEAD,,

Allow: POST,OPTIONS,,HEAD,:09:44 GMT

Allow: GET,HEAD,OPTIONS,,HEAD,,HEAD,,HEAD,, HEAD,,HEAD,,HEAD,,HEAD,POST,,HEAD,, HEAD,!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"

Allow: GET,HEAD,OPTIONS,=write HTTP/1.0,HEAD,,HEAD,POST,,HEAD,TRACE

這看起來很有趣, 而且很危險。它看起來就像是一個 "出血" 式的漏洞，而且已經成為這個漏洞的http Options出血漏洞，該漏洞將導致內存泄漏給潛在的攻擊者。然而, 這些是隨機的伺服器在互聯網上, 所以起初我不知道是什麼軟體造成的。

有時 HTTP 伺服器發送一個 "Server" 報頭告訴軟體。然而, 你需要知道, "server" 頭部是可以說謊的。這在HTTP 服務代理中很常見。所以，我得到了各種不同的 "Server" 標題, 但我很懷疑這些都是來自同一個 漏洞。

Options出血漏洞

Options出血是在 Apache http 中釋放錯誤後使用的, 這會導致在響應 HTTP 選項請求時構造一個損壞的Allow標頭。這可能會泄漏可能包含機密的伺服器進程中的任意內存片斷。在多個請求之後, 內存塊會發生變化, 因此對於易受攻擊的主機, 可以泄漏任意數量的內存塊。

如果網站管理員對無效的 HTTP 方法實施 "Limit" 指令, 則會出現此問題。

Example .htaccess:

影響範圍待評估 但Alexa排名前100萬的網站中有466台受影響

在Alexa排名前100萬網站中，顯示了466台主機存在損壞的Allow頭部，這些網站的影響面和用戶群都非常龐大。理論上, 其他伺服器軟體可能有類似的錯誤。另一方面, 此漏洞是非確定性的, 因此並非所有易受攻擊的主機都可能被捕捉。

因此, 如果你設置一個非常不尋常的配置選項，就會發生這個問題嗎？

在共享的託管環境中存在額外的風險。損壞不限於單個虛擬主機。共享宿主提供程序的一個客戶可能會故意創建一個. htaccess 文件, 從而導致這方面的問題, 而且能夠從同一系統上的其他主機提取機密數據。

Apache給出了回應

我試圖聯繫受影響的伺服器運營人員, 但對方非常不願意告訴我任何關於他的設置, 所以也沒法進行確認。但是, 我找到一個辦法，一些損壞的報頭中包含了 Apache 清晰的配置選項字元串。這些字元串似乎不太可能出現在其他伺服器軟體的內存中。但我無法在自己的 Apache 伺服器上重現任何類似的東西。我還嘗試閱讀哪些放在一起Allow頭部的代碼，看看是否能找到任何線索, 但沒有成功。所以不知道任何細節，沒辦法了，我聯繫了 Apache 安全小組。

幸運的是Apache開發商Jacob Champion發現了這個問題, 並想通了什麼是怎麼回事:

apache 支持配置指令Limit，允許限制對特定用戶的某些 HTTP 方法的訪問。如果在. htaccess 文件中為未在伺服器上全局註冊的 HTTP 方法，設置了限制指令, 則會發生損壞。

ok，知道這個問題之後, 我可以自己重新這個漏洞了。在. htaccess 文件中為任何無效的 HTTP 方法設置Limit指令後, 在Allow報頭的構造中就出現了問題, 同時還可以被Address Sanitizer檢測到。(但是, 由於 APR 執行的內存分配抽象, ASAN的工作不可靠。

https://blog.fuzzing-project.org/uploads/optionsbleed-asan.txt

poc地址：https://github.com/hannob/optionsbleed

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！