アカウント名:
パスワード:
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
ここに echo vulnerable 書き足せるシチュエーションだと関数 () { :;} の中も好き放題出来そうな気がするんだけどそれは気のせいなの？
「(){～}」の部分は関数の定義の部分で、その関数定義を環境変数にセットされるところまでは良くて、環境変数にセットされただけだと、誰かがその環境変数に入っている関数を叩かないと実際の処理は発生しない。
ところが、その直後の「;」の後ろ、関数定義の外側のにある部分を bash が勝手に実行してしまう、というのが今回の脆弱性。
...と理解しているけど合ってるかな？
env echo='() { ls; }' bash -c 'echo hoge'とかできる時点で、環境変数で関数定義を渡せるという機能自体が、今回の問題と大差ない脆弱性のような気がする
env echo='() { ls; }' bash -c 'echo hoge'のような攻撃はスクリプト側(or bash経由で起動されるプロセス)で対処できます．例えば echo という変数を再定義するなり/bin/echo を使うようフルパスを記述するだけです．ですので，これはスクリプト側の脆弱性と捉えるべきだと思います．つまりスクリプト側を修正すべきです．
しかしenv x='() { :;}; echo vulnerable' bash -c "echo this is a test"この攻撃は スクリプト側では対処できません．スクリプト側で対処できないので，これは bashの脆弱性で，bash側で対処すべき問題だと思います．
>のような攻撃はスクリプト側(or bash経由で起動されるプロセス)で対処できます．
export unset='() { ls; }'とされてしまったら、環境変数経由で渡ってくる関数を消そうにもできないわけだが。unset 以外にも回避手段はあるかもしれないが、unset 同様に関数で上書きされてしまったら手も足も出ない。cd のように外部コマンドではなくシェルのビルトインでないと実現できない機能はフルパスで指定することもできないし。なので、これをスクリプトの脆弱性とするのは無理がある。
Bourne sh にはなかった機能であって、bsh では気にする必要のなかったことでもあるし、bash の脆弱性以外の何ものでもない。
cd のように外部コマンドではなくシェルのビルトインでないと実現できない機能はフルパスで指定することもできないし。
えっ
[foo@bar ~]$ which cd/usr/bin/cd
/usr/bin/cd の中身はシェルスクリプトで、 "builtin cd" を実行。
自己レスだけど、 /usr/bin/cd は builtin の cd の代替にはならないのか。
[foo@bar ~]$ pwd/home/foo[foo@bar ~]$ /usr/bin/cd /[foo@bar ~]$ pwd/home/foo[foo@bar ~]$ cd /[foo@bar /]$ pwd/
/usr/bin/cd はサブシェルで実行されるので、呼出元のシェルでは cd されないということで合っているかな?じゃあなんで /usr/bin/cd が用意されているのだろう…?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
イマイチ理解できないんだけど (スコア: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: (スコア:2)
env echo='() { ls; }' bash -c 'echo hoge'
のような攻撃はスクリプト側(or bash経由で起動されるプロセス)で対処できます．
例えば echo という変数を再定義するなり
/bin/echo を使うようフルパスを記述するだけです．
ですので，これはスクリプト側の脆弱性と捉えるべきだと思います．つまりスクリプト側を修正すべきです．
しかし
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
この攻撃は スクリプト側では対処できません．
スクリプト側で対処できないので，これは bashの脆弱性で，bash側で対処すべき問題だと思います．
Re:イマイチ理解できないんだけど (スコア:0)
>のような攻撃はスクリプト側(or bash経由で起動されるプロセス)で対処できます．
export unset='() { ls; }'
とされてしまったら、環境変数経由で渡ってくる関数を消そうにもできないわけだが。
unset 以外にも回避手段はあるかもしれないが、unset 同様に関数で上書きされてしまったら手も足も出ない。
cd のように外部コマンドではなくシェルのビルトインでないと実現できない機能は
フルパスで指定することもできないし。
なので、これをスクリプトの脆弱性とするのは無理がある。
Bourne sh にはなかった機能であって、bsh では気にする必要のなかったことでもあるし、
bash の脆弱性以外の何ものでもない。
Re: (スコア:0)
えっ
/usr/bin/cd の中身はシェルスクリプトで、 "builtin cd" を実行。
Re: (スコア:0)
自己レスだけど、 /usr/bin/cd は builtin の cd の代替にはならないのか。
/usr/bin/cd はサブシェルで実行されるので、呼出元のシェルでは cd されないということで合っているかな?
じゃあなんで /usr/bin/cd が用意されているのだろう…?
Re: (スコア:0)
# といった使い道が cd(1) に記述されていました。