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

Question

一部の人々を安心させるために、私は脆弱性を見てバグを発見したわけではなく、それが公開される前に悪用されたと信じる理由はありません（もちろんこの可能性を排除することはできませんが）。bashコードを探しても出ませんでした。

私は私が何を考えたか正確に覚えていると言うことはできません。

これは、私が見つけたいくつかのソフトウェアの特定の動作のいくつかの反映に基づいています。危険（ソフトウェアではなく行動）。そのような行動は次のような考えをさせます。良い考えではないようです。。

この例では、名前がで始まる場合、クライアントがクリーンアップされていない環境変数を渡すことができるsshの一般的な設定を反映していますLC_。アイデアは、人々が他のコンピュータ言語にログインしたときに自分の環境変数を引き続き使用できるようにすることですssh。特にUTF-8を考えると、ローカライズ処理がどれほど複雑であるかを考え始めるまで（そしてそれを処理するアプリケーションがどれほど不足しているかを確認するまで）、これは良い考えです。

sshd 2014年7月、私はこの構成と組み合わせたglibcのローカライズ処理の脆弱性を報告しました。残りの2つ危険な行動bashシェル認証された攻撃者がgitサーバーにファイルをアップロードし、bashそれをgit unixユーザーのログインシェルとして使用できる場合、そのサーバーを破損する可能性があります（CVE-2014-0475）。

私はsshを介して提供されるユーザーのためのログインシェルとしてそれを使用するのはおそらく悪い考えだと思います。bashなぜなら、これはかなり複雑なシェル（必要なのは非常に単純なコマンドラインを解析するだけです）であり、ほとんどのバグDesign Kshを継承するからです。その文脈でこれを使用してすでにいくつかの問題を発見しているのでbash（sshの説明ForceCommand）、より多くの問題があるかどうか疑問に思います。

AcceptEnv LC_*名前で始まるすべての変数を受け入れますLC_。漠然と覚えていますね。bash エクスポート機能（ㅏ危険時には役に立つ機能ですが）同様の名前の環境変数を使用していて、それに 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/...env QUERYSTRINGvars)、メール処理サービス、以後DHCP（おそらく長いリスト）などを通じても悪用されることができることを確認し、これを見て（慎重に）しました。）。

Answer 1