作者 Paul Ducklin
還記得 Heartbleed 嗎？
這是一個奇怪的錯誤 (bug)，起源於 OpenSSL 中一個稱為 “heartbeat” 的功能。想存取伺服器的訪客可以對它發送一個短訊息，例如 HELLO，然後等待相同的短訊息回傳，以便證明連線還有效。
Heartbleed 弱點是，您可以偷偷要求伺服器回覆比初始發送資料更多的資訊。伺服器不會忽略這個格式錯誤的請求，而是會回傳您的資料…
… 再加上在記憶體中的一些東西，即使是個人資料，例如其他人網頁工作階段中的瀏覽歷史記錄，或網頁伺服器本身加密金鑰等私密資料。
這種作法不需要認證的工作階段、遠程插入可執行命令、猜測密碼或任何其他類型的駭客入侵步驟。
偷竊者可能會一遍又一遍地向伺服器詢問看似無害的相同問題，然後追蹤每次偷到的資訊並深入挖掘出他們有興趣的東西
好吧，類似的事情又發生了。
這次，錯誤並不是存在於 OpenSSL 中，而是在一個名為 httpd 的程序中，也就是廣為周知的 Apache Web Server，正式名稱為 Apache HTTP Server Project。
該弱點被稱為 OptionsBleed，因為該錯誤是透過 HTTP OPTIONS 請求觸發的。
如果您了解 HTTP，可能會聽過 GET 和 POST 請求。它們通常被用來擷取資料或網頁，或是用於上傳檔案或填寫表單。
但是還有許多其他 HTTP 請求類型，如官方稱為的「方法」 (method)，包括：
- PUT：在網頁資料庫新增一個新項目。
- PATCH ：編輯網頁資料庫中的現有項目。
- DELETE ：刪除指定的項目。
- HEAD：如同 GET，但只發送標頭而省略內文。
- TRACE ：回覆上傳的資訊以供偵錯之用。
並不是所有網頁伺服器都支援所有的官方方法，所以有一個特殊方法可以協助判別：
- OPTIONS：回報特定網頁可以使用的方法。
藉由 OPTIONS，您可以避免使用永遠無法使用的請求來聯繫網頁伺服器，避免連線失敗並浪費伺服器的資源。
例如：
$ wget -S –method=OPTIONS https://my.example/index.html
HTTP request sent, awaiting response…
HTTP/1.1 200 OK
Allow:OPTIONS, TRACE, GET, HEAD, POST
Public:OPTIONS, TRACE, GET, HEAD, POST
Content-Length:0
Date:Tue, 19 Sep 2017 14:09:26 GMT
$
上例中，您可以看到 my.example 伺服器可以支援的方法列出於 Allow: 標頭中。
看起來很安全啊，您或許會這麼想 – 而且這就是它的功能吧。
但是軟體和安全研究人員 Hanno Böck 另有發現。
他對 Alexa 前 100 萬個網站所支援的 OPTIONS 進行了調查，依次詢問每個網站。
Böck 發現，一小部分伺服器回傳亂碼或者看似損毀的回應，例如：
Allow: ,GET,,,POST,OPTIONS,HEAD,,
Allow:POST,OPTIONS,,HEAD,:09:44 GMT
Allow:GET,HEAD,OPTIONS,=write HTTP/1.0,HEAD,,HEAD,POST,,HEAD,TRACE
Böck 列出一項看起來很像是「bleed 類型」的資料外洩：
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”
不僅許多選項可疑且奇怪地重複，而且伺服器回傳的是一個看似網頁的片段 (如 HTTP 回應內文的內容)，而不是 OPTIONS 的回應 (通常沒有任何內文內容)。
什麼地方有問題？
Böck 發現到在這些問題回覆中有資料外洩，強烈認為與 Apache 伺服器有關。(有些外洩的資料顯然是 Apache 的組態設定)
在 Apache 開發人員 Jacob Champion 的協助下，他們追根究底，發現這個錯誤很有意思 – 這是一個好例子，提醒我們一個不重要的錯誤能造成多大的影響。
首先我們先了解一些背景。
我們可以透過將稱為 .htaccess 的檔案放在伺服器的樹狀目錄中來設定 Apache 伺服器。
每個.htaccess 檔案會為它所在和其下的目錄設定組態選項，除非它們的設定被另一個更低階層的 .htaccess 檔案覆蓋。
雖然從伺服器磁碟空間的角度來看，這種 Apache 組態設定的作法有負面影響，但是從好的角度來看，它可以安全地讓一部伺服器和一個樹狀目錄同時服務許多不同的網站 (術語稱為虛擬主機)。
無論虛擬主機是否代表同一組織內的多個部門，或是個別公司購買的虛擬主機共用服務，每個客戶都可以擁有自己的子樹狀目錄。
子樹狀目錄會安全地鎖定成預設樹狀目錄的頂部；若想更為仔細，每個客戶還可以重新配置他們所使用的這部分伺服器。
託管公司不需要為每個客戶配置一部電腦、一個虛擬機和一個運作中的 httpd，而是可以安全地將一部功能強大的伺服器分配給 (理論上) 眾多的網站和客戶。
您可以在 .htaccess 檔案中新增一個設定 (Apache 用了很官僚的名稱「指令 」(directives) 來稱呼這些設定)，亦即 Limits。顧名思義，這個設定會限制當前樹狀目錄中可以使用的 OPTIONS。
例如：
<Limits POST PATCH PUT DELETE>
Deny from all
</Limits>
如果您的網站樹狀目錄中有一部分只是用於提供檔案，那麼這種限制可以派上用場。這界如何 “減少受攻擊面” 的一個很好的例子。您還可以更進一步，避免所有人都一直以系統管理員的身分登入。
但是有一點：如果您在一個指令中設定的某個 HTTP 方法不適用，那麼就會觸發 “Optionbleed” 的錯誤。
所謂不適用，指的是在全域 httpd 組態設定中已經停用了該方法，或者該方法實際上不存在。例如您輸入的是 DELLETE 而非 DELETE。
您或許會覺得這不重要，除了在某個日誌檔中出現一個警告之外。禁用已經被禁用的選項或停用不存在的選項是浪費時間，但事情應該不會更糟。
然而，設置一個不存在 (或不適用) 的 Limit，會讓 Apache 釋放不再需要的記憶體…
… 但仍會繼續參照到該記憶體空間，甚至是在另一部分的 Apache 程式被分配到並使用之後。
這個ˊ錯誤的名稱顧名思義，被稱為 use-after-free，您可以看到這些錯誤如何造成資料外洩的弱點：您可以輕鬆地取得別人的資料，甚至可以複製一些個人或私人資訊，並將其經由網路傳送出去。
所以，根據 Böck 和 Champion 的發現，當 Apache 處理一個原本目的是提高安全性的 .htaccess 檔案時，就會觸發一個記憶體管理不當的錯誤…
…最後，當完全不同的 Apache 元件處理 OPTIONS 請求時，就會導致外洩資料，安全性降低。
因此稱為 Optionbleed。
情況有多嚴重？
好消息是，這個錯誤的負面效應似乎並不常見，因為必須同時設定不正確的 .htaccess 檔案和剛好不合時宜的 OPTIONS 請求才會觸發。
事實上，Böck 對 100 萬台不同的網路伺服器測試了 466 個 “Optionbleed”。(由統計數據可以得知，其中約有 40 萬部伺服器運作 Apache，而會造錯誤觸發的易受攻擊約佔 0.12％)
然而，請記住，一部伺服器會在不同樹狀目錄中託管許多部虛擬主機。一個惡意的客戶可能會在自己的 .htaccess 中故意設定一個無效選項來觸發這個錯誤，然後重複造訪一個他們自己的 URL 來查看有哪些資料外洩。
會外洩的資料均來自於 Apache 伺服器軟體的記憶體，理論上也會包含來自其他客戶的內容，也可能是來自伺服器本身。
同樣的，無心的客戶可能也會造成問題。例如他們會從組態範本複製和貼上一個 .htaccess 檔案，但是順理成章地保留多餘的選項。正如我們上面提到的，他們覺得停用已經停用的選項應該是無害的。
該怎麼辦？
幸運的是，有一個修補程式可用：Apache 開源程式碼伺服器已經提供了一個 針對 Optionbleed 的修補程式 。
如果您將伺服器或虛擬主機委外，請詢問您的供應商是否可以為您安裝該修補程式。
不幸的是，在撰寫本文 (2017-09-19) 時，Apache 還沒有發佈正式通告或官方更新的 Apache 版本。因此目前您仍需要自行套用程式碼並更並重新編譯更新版本的 httpd。
當然，未經 Apache 官方核可，我們很難判斷目前可用的修補程式是否是修正這個錯誤的最佳且最安全的方法。
所以，如果您不能或不想立即修補，我們建議您檢查所有 .htaccess 檔，找出不適用的設定 (或拼寫錯誤)，即使是不必要刪除的合法和有用設定，不過在目前的設定中是多餘的。
無論您選擇哪種作法，請留意 Apache 的下一次官方安全更新 – 目前的修補程式可能會被替換、改進、擴展或取代。
英文原文: https://nakedsecurity.sophos.com/2017/09/19/apache-optionsbleed-vulnerability-what-you-need-to-know/
(本博文為翻譯本，內容以英文原文為準)
Leave a Reply