GNU Bashに重大な脆弱性、環境変数を渡して呼ぶことで任意コード実行が可能に 48
ストーリー by hylom
これは影響が大きそうだ 部門より
これは影響が大きそうだ 部門より
90 曰く、
GNU Bashに新たな脆弱性が発見された（CVE-2014-6271）。環境変数を経由して関数定義を渡す場合に、細工をしてコマンドを実行させることができる。攻撃に使う環境変数の名前に制限はなく、たとえば内部的にshを実行するようなCGIに対してHTTP ユーザーエージェントを送る際や、ssh接続時に環境変数を渡す時など、環境変数を改変した状態でbashが呼ばれるようになっていれば攻撃ができる（ThreatPost、CSO Online）。
この脆弱性はすべてのバージョンの bashにあるとされ、Mac OS Xにも当該のバージョンが含まれるとされている。一部の Linux ディストリビューションではすでにアップデートを配布している。
Red Hat Security Blogによると、脆弱性のあるバージョンでは以下の"echo vulnerable"の部分が予期せず実行される。
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
M$製品は危険(笑) (スコア:2)
OSSなら安全(爆笑)
Microsoft大勝利！ (スコア:1)
Microsoftはbashという邪悪な危険ソフトウェアを利用しない唯一のソフトウェアです！
Re:Microsoft大勝利！ (スコア:2, おもしろおかしい)
bashへのbashingはやめていただきたい！
Re: (スコア:0)
(brainを) wash するOSが何を言うか！
Windows以外のOSは致命的な不具合ばかりだなあ (スコア:1)
Windows以外のOSは致命的な不具合ばかりだなあ
Re: (スコア:0)
心配なのは、この脆弱性の影響をモロに受けるLinuxサーバは非常にたくさんあって、かつ、かなりの割合のサーバがアップデートされないまま放置されるであろうということです。
アップデートは難しくないでしょうけれど、それでもアップデートしないサーバ管理者は少なくないでしょう。
Appleのサーバは多くは無いですが、修正パッチすら提供されていませんし。
Re: (スコア:0)
アップデートしたから安心（笑）
ではないよ今回は
Re: (スコア:0)
あなたの知っているWindows以外のOSと致命的な不具合ばかりのOSを列挙してもらえませんか？
「みんな持っているから買って」と同じレベルじゃない事を期待しています。
Re: (スコア:0)
といえば真っ先にiOSが思い浮かびますね。あと、Mac OSXも。
Re: (スコア:0)
この程度の脆弱性ごときで
問答無用でカレントディレクトリにパスが掛かっていることになっている、
Windowsにかなうものか。
脆弱性入りだと具体的にどうなるの (スコア:0)
Linuxのだと
こんな感じ。
Cygwinのだと
こんな感じ。
違いが全くわからない。
Cygwinの4.1系でも脆弱性無さげだけど。
Re:脆弱性入りだと具体的にどうなるの (スコア:2)
うちのCygwin だと、こんな感じでふ。
$ bash --version
GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
svn-init() {
svnadmin create .svnrepo
svn checkout file://$PWD/.svnrepo .
}
Re:脆弱性入りだと具体的にどうなるの (スコア:2)
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
$
ありだと上のようになるそうです。すべてのバージョンってのが間違ってて、つい最近のものだったりするのか…
あと修正が不十分だという発言を見かけたのですが、認識された [redhat.com]ようです。
Re: (スコア:0)
ってのが多分今回のパッチで追加された warning メッセージなので、元コメの人のは既に patch 適用済なのではと思います。
ディストリビューションに付属のものはバージョン番号を上げずに脆弱性対策のパッチだけを当てることがあるので、バージョン番号のみで判断できないというのはまぁいつものことですね。
Re: (スコア:0)
どっちも対策済みじゃん
Re: (スコア:0)
これってSELinuxとかを有効にしてても緩和できなかったりするんですかね
まだ万全じゃないよという突っ込み (スコア:0)
CVE-2014-6271 [redhat.com]のComment 23, 24辺り。
Re:まだ万全じゃないよという突っ込み (スコア:1)
そこのComment27によるとworkaroundはこちら [redhat.com]
LD_PRELOADでパッチを読ませるんですって。
環境変数で出てるバグのパッチを読ませるのに環境変数を使うのってなんだかこそばゆい。
Re:まだ万全じゃないよという突っ込み (スコア:1)
新しい方にはCVE-2014-7169 [nist.gov]が採番されてますね。
元ネタでは $ x='() { (a)=>\' sh -c 'echo date';cat echo ですけど、Ubuntuだと /bin/sh は dash なので再現できませんでした。
$ x='() { (a)=>\' sh -c 'echo date';cat echo
date
cat: echo: そのようなファイルやディレクトリはありません
これを、こう
$ x='() { (a)=>\' bash -c 'echo date';cat echo
bash: x: 行 1: 予期しないトークン `=' 周辺に構文エラーがあります
bash: x: 行 1: `'
bash: `x' の関数定義をインポート中にエラーが発生しました
2014年 9月 25日 木曜日 16:22:24 JST
オナニーコーディングの極み (スコア:0)
誰だか知りませんが、このバグ作り込んだキチガイは、
1. 「環境変数に関数埋め込めたら超Coolじゃね？俺って天才！」と思いついて
2. 関数の解釈を横着するために何が入ってるかもわからないstringをevalする実装を考えついて
3. それを実装するときにバグを埋め込んで
4. 世界中のUnix系システムを危険に晒した
わけですね！
二度とソフトウェアの世界に関わらないでもらいたい
Re:オナニーコーディングの極み (スコア:2)
子プロセスに関数定義を引き継ぐためのなんだかんだと聞いたような。まあwebからアクセスできるとこで一切bashなんかinvokeしなけりゃいいんですよ。
そんなことをしているつもりの人はごくごくごくごく一部だったんでしょうけど、まあ。
Re: (スコア:0)
そろそろevalじゃなくてevilに名前を変えよう（無理）
Re: (スコア:0)
> 二度とソフトウェアの世界に関わらないでもらいたい
作者結構強そうだけど、面と向かってそのセリフ言えんの？
http://en.wikipedia.org/wiki/Brian_Fox_(computer_programmer) [wikipedia.org]
君がbash書いてればbashされることはなかっただろうに残念ですね。
Re: (スコア:0)
ぜひハードゲ…ウェアに専念してほしい
Re: (スコア:0)
こういう無謬主義こそソフトウェアの世界で最も忌み嫌われるべきものだと思うんだけど。
石を投げていいのは (スコア:0)
バグを出したことがないやつだけだ。
Re: (スコア:0)
それ言っちゃうと使うだけのタダノリユーザーが嬉しそうに投石しまっせ
Re: (スコア:0)
なんというか無産・搾取に徹したフリーライダー特有の傲慢さが滲み出てますよね。
Re:オナニーコーディングの極み (スコア:1)
ライ"ダ"ー？
#プライドすらないという意味ではこれでもあながち間違いではないというのがなんとも。
Re: (スコア:0)
ライ"ダ"ー？
free rider [wikipedia.org]
Re: (スコア:0)
間違えるのは仕方ないけど、間違いを重ねることは擁護できません
1.～3.はそれぞれが超ド級の大間違いで、それが3つも重なったからこんな大騒ぎになってるわけでしょ？
Re: (スコア:0)
そんな話じゃない。もっと歴史を勉強すべし。
Re: (スコア:0)
ローカル環境で完結するプログラムだと思ってると、無茶な曲芸やっちゃう事もあるかな。
イマイチ理解できないんだけど (スコア:0)
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
ここに echo vulnerable 書き足せるシチュエーションだと
関数 () { :;} の中も好き放題出来そうな気がするんだけどそれは気のせいなの？
Re:イマイチ理解できないんだけど (スコア:2)
「(){～}」の部分は関数の定義の部分で、その関数定義を環境変数にセットされるところまでは良くて、環境変数にセットされただけだと、誰かがその環境変数に入っている関数を叩かないと実際の処理は発生しない。
ところが、その直後の「;」の後ろ、関数定義の外側のにある部分を bash が勝手に実行してしまう、というのが今回の脆弱性。
...と理解しているけど合ってるかな？
Re: (スコア:0)
env echo='() { ls; }' bash -c 'echo hoge'
とかできる時点で、
環境変数で関数定義を渡せるという機能自体が、
今回の問題と大差ない脆弱性のような気がする
Re:イマイチ理解できないんだけど (スコア:1)
env echo='() { ls; }' bash -c 'echo hoge'
他の方のコメントでも書かれていますが、これだと「bash -c」に渡している「echo hoge」の部分を攻撃者が挿入できるか、もしくは、事前に bash 経由で echo を実行する事が分かっている場合になります。前者だと、この問題が無くても外部から任意の実行できることになるので、この脆弱性以前の話だし、後者だと狙った動きをするためには、事前に bash が実行する内容を知っている事が必要、という事になると思います。
少なくとも、今回の脆弱性があれば、bash が本来実行しようとしている内容にかかわらず、環境変数さえ設定できれば任意のコマンドが実行できます。「-c 'echo hoge'」の部分すら必要ありません。
ただ、確かに、bash が本来、実行しようとしているコマンドを置き換える事が可能、という点は、条件がそろうと現実的な問題になりうると思います。通常、関数の方が PATH で見つかるコマンドや内部コマンドよりも優先順位が高いですが、環境変数経由で渡ってくる関数も、同様の優先順位で良いのか、という気がします。環境変数経由の関数が通常のコマンドよりも低い優先順位であれば、コマンドの置き換えは避けられるのでは、と思いました。
Re: (スコア:0)
その方法で攻撃するためには、攻撃対象が任意の環境変数を渡せるサービスでないとならない。
攻撃対象が HTTP なら渡せる環境変数は HTTP_USER_AGENT 等に限られるし (多分) 、
他のサービスでもさすがに任意の環境変数を渡せるようなものは無いのでは。
(断言はできないけど。)
Re: (スコア:0)
curl とか rsync とかで 他サーバにデータ渡せないの？
Re: (スコア:0)
"echo vulnerable" は bash が起動された時点で実行されるけど、
関数 () { :; } の中は起動した bash の中でさらに x を実行しないと実行されない。
渡された環境変数名を関数として実行しているとか、任意の環境変数を渡せる
(=本来実行すべきコマンドが環境変数で上書きされる)とかいうことが無ければ
関数の中が実行されることは無いと思う。
どうしてこうなった (スコア:0)
・関数を定義できるようにしよう←分かる
・定義した関数をエクスポートできるようにしよう←分かる
・関数のエクスポートは環境変数でやろう←分かる
・環境変数に関数定義っぽいものがあったら全部評価することにしよう←うん……うん？
・評価は全部 eval するようにしよう←おいバカやめろ
シェルスクリプト高速開発手法入門 (スコア:0)
http://www.amazon.co.jp/gp/product/toc/4048660683/ref=dp_toc?ie=UTF8&a... [amazon.co.jp]
目次より。
Apacheを設定してCGIシェルスクリプトを動かす
shell四天王の中で最弱？ (スコア:0)
最強はzshなのかな
web serverのユーザーでアクセス? (スコア:0)
bashがweb serverのユーザーでアクセスできるのだとすれば、
apacheをroot で動かしていない限りは、問題は限定的では?
rm -rf / しても全部消えないから始末が悪いとも言えますが。
android のbusybox は？ (スコア:0)
https://twitter.com/pascal_gujer/status/515088698892115968 [twitter.com]
Android 4.4 のbusyboxで出たと言ってる人が居ますね
全ての環境にシェルが入ってるのが以上 (スコア:0)
アンドロイドやクロームにもシェルは必要なんでしょうか？
デスクトップや組み込み、CPUボード搭載のリナックスにはシェルは不要
Systemdにシェルコードが入っていたり、CoreOSのサービス起動にもシェルを使っていたりする
シェル使わずに別の言語で書けば速度も上がっていいのにと某掲示板で書いたらキレラレマシタ
Re:全ての環境にシェルが入ってるのが以上 (スコア:1)
Re: (スコア:0)
なくても作れるってのは同意だけど
あればあったで柔軟性が高まったり便利な使い方もあるのだから、要はバランスでしょ
使い道があるのに100%不要みたいな言い方したんじゃないの?