Shellshock Bashの脆弱性はどのように発見されましたか？

このバグは非常に多くのプラットフォームに影響を与えるため、この脆弱性が発見されたプロセスから何かを学ぶかもしれません。それはεὕρηκα（eureka）瞬間でしたか、またはセキュリティチェックの結果でしたか？

StéphaneがShellshockバグを発見したことを知っているので、他の人もプロセスを知っているかもしれないので、彼がどのようにしてバグを発見したかについての話に興味があります。

安心させるために、エクスプロイトを観察してバグを見つけませんでした。開示される前に悪用されたと信じる理由はありません（もちろん、それを除外することはできません）。bashのコードを見ても見つかりませんでした。

当時の自分の考えを正確に覚えているとは言えません。

それは多かれ少なかれ、私が危険だと思うソフトウェア（ソフトウェアではなく、行動）のいくつかの振る舞いに関するいくつかの反射から来ました。あなたが考えるようにする行動の種類：それは良いアイデアのように聞こえません。

この場合、名前がで始まる場合、クライアントから無害な環境変数を渡すことができるsshの一般的な構成について考えていましたLC_。アイデアは、ssh他のマシンに接続するときに人々が自分の言語を使い続けることができるようにすることです。特にUTF-8が方程式に組み込まれている場合（および多くのアプリケーションでどれだけひどく処理されているかを確認する場合）、ローカライズ処理がどれほど複雑であるかを検討し始めるまでは良い考えです。

戻る2014年7月で、私はすでにそれと組み合わせたglibcローカライズ処理の脆弱性報告していたsshd 設定を、そして他の二つの危険な行動のbashシェル gitのサーバに侵入する許可（認証済み）攻撃者は、彼らがそこにファイルをアップロードすることができました提供し、bash使用されましたgit unixユーザーのログインシェルとして（CVE-2014-0475）。

bashssh経由でサービスを提供するユーザーのログインシェルとして使用するのはおそらく悪い考えだと思っていました（非常に単純なコマンドラインを解析するだけで十分な場合）、ほとんどの誤設計を継承しているためですkshの。bashそのコンテキストで（sshを解釈するためにForceCommand）使用する際にいくつかの問題を既に特定しているので、潜在的にもっとあるのではないかと考えていました。

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（およびおそらく長いリスト）などの他の脆弱性も悪用できることを確認し、（慎重に）報告しました。