Shellshock Bash 漏洞是如何被發現的？
由於這個漏洞影響了這麼多平台，我們可能會從發現這個漏洞的過程中學到一些東西：它是 εὕρηκα (eureka) 時刻還是安全檢查的結果？
由於我們知道 Stéphane 發現了 Shellshock 漏洞，而且其他人可能也知道這個過程，我們會對他如何找到漏洞的故事感興趣。
為了讓一些人放心，我沒有通過觀察漏洞發現漏洞，我沒有理由相信它在被披露之前就被利用了（當然我不能排除它）。我也沒有通過查看
bash’s code 找到它。我不能說我完全記得我當時的構想。
這或多或少來自對我認為危險的某些軟體的某些行為（行為，而不是軟體）的一些反思。那種讓你思考的行為：這聽起來不是個好主意。
在這種情況下，我正在思考 ssh 的常見配置，它允許傳遞未經客戶端處理的環境變數，前提是它們的名稱以
LC_.ssh這個想法是為了讓人們在使用其他機器時可以繼續使用自己的語言。一個好主意，直到您開始考慮本地化處理的複雜性，尤其是當 UTF-8 被納入等式時（並且看到許多應用程序處理它的糟糕程度）。早在 2014 年 7 月，我已經報告了 glibc 本地化處理中的一個漏洞，該漏洞與該
sshd配置相結合，並且shell的另外兩個危險行為bash允許（經過身份驗證的）攻擊者入侵 git 伺服器，前提是他們能夠在那裡上傳文件bash並被使用作為 git unix 使用者的登錄 shell (CVE-2014-0475)。我認為將其用作通過 ssh 提供服務的使用者的登錄 shell 可能是一個壞主意
bash，因為它是一個相當複雜的 shell（當你只需要解析一個非常簡單的命令行時）並且繼承了大多數錯誤設計ksh的。由於我已經確定了bash在該上下文中使用的一些問題（解釋 sshForceCommands），我想知道那裡是否可能存在更多問題。
AcceptEnv LC_*允許任何名稱以開頭的變數，LC_並且我模糊地記得bash導出函式（一個危險的，儘管有時有用的功能）正在使用名稱類似的環境變數，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（可能還有很長的列表）並報告（小心） .