Shellshock Bash 漏洞是如何發現的？

Question

為了讓一些人放心，我沒有透過觀察漏洞發現該錯誤，我沒有理由相信它在被披露之前就已經被利用了（儘管我當然不能排除這種可能性）。我也沒有通過查看bash它的代碼找到它。

我不能說我清楚記得我當時的想法。

這或多或少來自於我發現的一些軟體的某些行為的一些反思危險的（行為，而不是軟體）。那種行為會讓你思考：這聽起來不是一個好主意。

在本例中，我反思了 ssh 的常見配置，該配置允許傳遞來自客戶端的未經清理的環境變量，前提是它們的名稱以LC_.這個想法是為了讓人們在ssh進入其他機器時可以繼續使用自己的語言。這是一個好主意，直到您開始考慮本地化處理有多麼複雜，特別是當 UTF-8 被納入考慮範圍時（並看到許多應用程式處理它的方式有多糟糕）。

早在 2014 年 7 月，我就已經報告了 glibc 本地化處理中的一個漏洞，該漏洞與該sshd 配置相結合，並且另外兩個危險行為bash殼的允許（經過驗證的）攻擊者侵入 git 伺服器，前提是他們能夠在那裡上傳檔案並bash用作 git unix 使用者的登入 shell (CVE-2014-0475)。

我認為將其用作bash透過ssh 提供服務的使用者的登入shell 可能是一個壞主意，因為它是一個相當複雜的shell（當您需要的只是解析一個非常簡單的命令列時）並且繼承了大部分錯誤設計克什。由於我已經發現了在該上下文中使用的一些問題bash（解釋 ssh ForceCommand），我想知道是否還有更多問題。

AcceptEnv LC_*允許任何名稱開頭的變量LC_，我模糊地記得bash 導出函數（A危險的儘管有時有用的功能）正在使用名稱類似的環境變量 myfunction()，並且想知道那裡是否沒有有趣的東西。

我正要駁回它，因為人們能做的最糟糕的事情就是重新定義一個名為的命令，LC_something 這實際上不會成為問題，因為這些不是現有的命令名稱，但後來我開始想知道如何bash 進口的那些環境變數。

LC_foo;echo test; f()例如，如果呼叫變數怎麼辦？所以我決定仔細看看。

A：

$ env -i bash -c 'zzz() { :;}; export -f zzz; env'
[...]
zzz=() {  :
}

揭示了我的記憶是錯誤的，因為變數沒有被調用myfunction()但是myfunction（而且它是價值以 ) 開頭()。

快速測試一下：

$ env 'true;echo test; f=() { :;}' bash -c :
test
bash: error importing function definition for `true;echo test; f'

證實了我的懷疑，變數名稱沒有被清理，並且程式碼被評估啟動時。

更糟的是，更糟的是，價值也沒有經過消毒：

$ env 'foo=() { :;}; echo test' bash -c :
test

這意味著任何環境變數可以是向量。

就在那時，我意識到問題的嚴重程度，確認它也可以透過 HTTP（HTTP_xxx/ QUERYSTRING... env vars）、其他諸如郵件處理服務、後來的DHCP（可能還有很長的列表）來利用，並報告它（仔細地）。

Answer 1