このバグは非常に多くのプラットフォームに影響するため、この脆弱性が発見されたプロセスから何かを学べるかもしれません。それはひらめきの瞬間だったのか、それともセキュリティ チェックの結果だったのか?
ステファンが Shellshock バグを発見したことはわかっていますし、他の人もそのプロセスを知っているかもしれないので、彼がどのようにしてバグを発見したのかという話に興味があります。
答え1
何人かの人たちを安心させるために言っておきますが、私はエクスプロイトを観察してバグを見つけたわけではなく、公開される前にエクスプロイトされたと信じる理由はありません (もちろん、それを否定することはできませんが)。bashのコードを見ても見つけられませんでした。
当時の自分の考えを正確に覚えているとは言えません。
それは、私が見つけたいくつかのソフトウェアの挙動についての考察から生まれたものです。危険な(ソフトウェアではなく動作)。考えさせるような動作:それは良い考えではないようだ。
この場合、私は、名前が で始まる場合に、クライアントからサニタイズされていない環境変数を渡すことができる ssh の一般的な構成について考えていましたLC_。そのアイデアは、他のマシンに を渡すときにユーザーが自分の言語を使い続けられるようにすることですssh。特に UTF-8 が方程式に導入されると、ローカリゼーション処理がいかに複雑になるかを考え始めるまでは (そして、多くのアプリケーションで UTF-8 がいかに不適切に処理されているかを見て)、良いアイデアです。
2014年7月に、私はすでにglibcのローカリゼーション処理の脆弱性を報告しており、それがこのsshd
設定と組み合わさって、他の2つ危険な行為bash殻のbash認証された攻撃者が git サーバーにファイルをアップロードし、 git unix ユーザーのログイン シェルとして使用した 場合に、git サーバーにハッキングすることができました(CVE-2014-0475)。
bashこれはかなり複雑なシェルであり (必要なのは非常に単純なコマンド ラインを解析することだけであるのに)、ksh の誤った設計のほとんどを継承していることを考えると、ssh 経由でサービスを提供するユーザーのログイン シェルとして使用するのはおそらくよくない考えだと考えていました。そのコンテキスト (ssh を解釈するため) で使用するといくつかの問題が発生することがすでにわかっていたので、bashさらに問題がForceCommand発生する可能性があるのではないかと考えていました。
AcceptEnv LC_*名前がで始まる変数なら何でも許可しますLC_。bash エクスポートされた関数（a危険な当時は便利な機能ではあったものの、次のような名前の環境変数を使用していたのです
myfunction()が、何か面白いものはないかと考えていました。
最悪のことは、LC_something
既存のコマンド名ではないコマンドを再定義することだということで、これを却下しようとしていたのですが、その後、bash
輸入されたこれらの環境変数。
LC_foo;echo test; f()たとえば、変数が呼び出された場合はどうなるでしょうか? そこで、詳しく調べてみることにしました。
答え:
$ 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 (おそらく長いリスト) など他のサービスでも悪用可能であることを確認し、それを (慎重に) 報告しました。