アカウント名:
パスワード:
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
ここに echo vulnerable 書き足せるシチュエーションだと関数 () { :;} の中も好き放題出来そうな気がするんだけどそれは気のせいなの？
「(){～}」の部分は関数の定義の部分で、その関数定義を環境変数にセットされるところまでは良くて、環境変数にセットされただけだと、誰かがその環境変数に入っている関数を叩かないと実際の処理は発生しない。
ところが、その直後の「;」の後ろ、関数定義の外側のにある部分を bash が勝手に実行してしまう、というのが今回の脆弱性。
...と理解しているけど合ってるかな？
env echo='() { ls; }' bash -c 'echo hoge'とかできる時点で、環境変数で関数定義を渡せるという機能自体が、今回の問題と大差ない脆弱性のような気がする
その方法で攻撃するためには、攻撃対象が任意の環境変数を渡せるサービスでないとならない。
攻撃対象が HTTP なら渡せる環境変数は HTTP_USER_AGENT 等に限られるし (多分) 、他のサービスでもさすがに任意の環境変数を渡せるようなものは無いのでは。(断言はできないけど。)
user agentみたいなどうでもいい変数をいじるだけでアタックできてしまうのがこの問題の怖さだろう。
個人で借りてるvpsサーバ（centos 5）のログを
grep '()' /var/log/httpd/access_log /var/log/httpd/ssl_access_log (←しょぼすぎるので、もっとましなの誰か作ってください、、、)
とかして、ざっと調べてみたけど、すでにアタックの形跡があった。
ひとつはrefererだか何かが"() { :; }; ping -c 11 209.126.230.74"となってるアクセスで、pingが帰れば脆弱性ありと判定できる仕組みであるらしい。ただこれは、http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html でバグの影響を調査しているらしく、悪質なものではないようだ。だた、もうひとつ別のアクセス（同じくpingの実行を狙ったもの）があって、それは本当にアタックしてきたものらしい。
うちの場合は404やら403のエラーになっていたので問題なかったけど、ちょっとぞっとした。速攻でbashをアップデートしたことは言うまでもない。
perlで作ったcgiなら、
$a=`echo hello`;
みたいなのがあったら、sh呼び出されてアウトになるわけで、それくらいのことなら私（=趣味でプログラムをいじる程度の人）は余裕でやっちゃってます。怖いよ。このバグ。
ここでの話って、UserAgent等による危険性は重大だけど、そもそも関数定義を渡せること自体も問題にならないかという話では？
"echo"等を再定義されちゃったりするとマズイよね？でも、そういう変数はhttp経由だといじれないか...という話になっていると理解しているんだけど。
curl とか rsync とかで 他サーバにデータ渡せないの？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
イマイチ理解できないんだけど (スコア:0)
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
ここに echo vulnerable 書き足せるシチュエーションだと
関数 () { :;} の中も好き放題出来そうな気がするんだけどそれは気のせいなの？
Re: (スコア:3, 興味深い)
「(){～}」の部分は関数の定義の部分で、その関数定義を環境変数にセットされるところまでは良くて、環境変数にセットされただけだと、誰かがその環境変数に入っている関数を叩かないと実際の処理は発生しない。
ところが、その直後の「;」の後ろ、関数定義の外側のにある部分を bash が勝手に実行してしまう、というのが今回の脆弱性。
...と理解しているけど合ってるかな？
Re: (スコア:0)
env echo='() { ls; }' bash -c 'echo hoge'
とかできる時点で、
環境変数で関数定義を渡せるという機能自体が、
今回の問題と大差ない脆弱性のような気がする
Re:イマイチ理解できないんだけど (スコア:0)
その方法で攻撃するためには、攻撃対象が任意の環境変数を渡せるサービスでないとならない。
攻撃対象が HTTP なら渡せる環境変数は HTTP_USER_AGENT 等に限られるし (多分) 、
他のサービスでもさすがに任意の環境変数を渡せるようなものは無いのでは。
(断言はできないけど。)
Re:イマイチ理解できないんだけど (スコア:1)
user agentみたいなどうでもいい変数をいじるだけでアタックできてしまうのがこの問題の怖さだろう。
個人で借りてるvpsサーバ（centos 5）のログを
grep '()' /var/log/httpd/access_log /var/log/httpd/ssl_access_log (←しょぼすぎるので、もっとましなの誰か作ってください、、、)
とかして、ざっと調べてみたけど、すでにアタックの形跡があった。
ひとつはrefererだか何かが"() { :; }; ping -c 11 209.126.230.74"となってるアクセスで、pingが帰れば脆弱性ありと判定できる仕組みであるらしい。ただこれは、http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html でバグの影響を調査しているらしく、悪質なものではないようだ。だた、もうひとつ別のアクセス（同じくpingの実行を狙ったもの）があって、それは本当にアタックしてきたものらしい。
うちの場合は404やら403のエラーになっていたので問題なかったけど、ちょっとぞっとした。速攻でbashをアップデートしたことは言うまでもない。
perlで作ったcgiなら、
$a=`echo hello`;
みたいなのがあったら、sh呼び出されてアウトになるわけで、それくらいのことなら私（=趣味でプログラムをいじる程度の人）は余裕でやっちゃってます。怖いよ。このバグ。
Re: (スコア:0)
ここでの話って、UserAgent等による危険性は重大だけど、そもそも関数定義を渡せること自体も問題にならないかという話では？
"echo"等を再定義されちゃったりするとマズイよね？でも、そういう変数はhttp経由だといじれないか...
という話になっていると理解しているんだけど。
Re: (スコア:0)
curl とか rsync とかで 他サーバにデータ渡せないの？