GNU Bashに重大な脆弱性、環境変数を渡して呼ぶことで任意コード実行が可能に 92
ストーリー 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"
例が分かり難い (スコア:5, 参考になる)
こんな感じで書いてくれれば危険性が分かり易いのになー
なるほど
User Agent Switcher で HTTP_USER_AGENT いじって
CGI で bash 呼んでるサービス閲覧するだけで撃が成立するわけだね。
確かにこれは怖いわ
uxi
Microsoft大勝利！ (スコア:3, おもしろおかしい)
Microsoftはbashという邪悪な危険ソフトウェアを利用しない唯一のソフトウェアです！
Re:Microsoft大勝利！ (スコア:3, おもしろおかしい)
bashへのbashingはやめていただきたい！
Re: (スコア:0)
(brainを) wash するOSが何を言うか！
まだ万全じゃないよという突っ込み (スコア:2, 興味深い)
CVE-2014-6271 [redhat.com]のComment 23, 24辺り。
Re:まだ万全じゃないよという突っ込み (スコア:2, 参考になる)
そこの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
android のbusybox は？ (スコア:1)
https://twitter.com/pascal_gujer/status/515088698892115968 [twitter.com]
Android 4.4 のbusyboxで出たと言ってる人が居ますね
見える！私にも見えるぞ！(by cmd.exe) (スコア:1)
A>set s=#{system('notepad')}
A>ruby -e "printf(\"%s%d\n\", 'aa',1)"
(Rubyのprintfで勝手にメモ帳が起動される)
Linuxにできて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:脆弱性入りだと具体的にどうなるの (スコア:1)
ってのが多分今回のパッチで追加された warning メッセージなので、元コメの人のは既に patch 適用済なのではと思います。
ディストリビューションに付属のものはバージョン番号を上げずに脆弱性対策のパッチだけを当てることがあるので、バージョン番号のみで判断できないというのはまぁいつものことですね。
Re:脆弱性入りだと具体的にどうなるの (スコア:1)
CentOS 6.5 x64 は対策済みのパッケージが配布されているみたいですね。
$ cat /etc/issue
CentOS release 6.5 (Final)
Kernel \r on an \m
$ rpm -qa | grep bash
bash-4.1.2-15.el6_5.1.x86_64
(@update http://mirror.centos.org/centos/6.5/updates/x86_64/Packages/ [centos.org] )
$ bash --version
GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
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.
$ export HTTP_USER_AGENT='() { :;}; echo dangerous injection'
$ bash -c "echo safe code"
bash: warning: HTTP_USER_AGENT: ignoring function definition attempt
bash: error importing function definition for `HTTP_USER_AGENT'
safe code
# SlashDot Light [takeash.net] やってます。
Re: (スコア:0)
どっちも対策済みじゃん
オナニーコーディングの極み (スコア:0)
誰だか知りませんが、このバグ作り込んだキチガイは、
1. 「環境変数に関数埋め込めたら超Coolじゃね？俺って天才！」と思いついて
2. 関数の解釈を横着するために何が入ってるかもわからないstringをevalする実装を考えついて
3. それを実装するときにバグを埋め込んで
4. 世界中のUnix系システムを危険に晒した
わけですね！
二度とソフトウェアの世界に関わらないでもらいたい
Re:オナニーコーディングの極み (スコア:5, おもしろおかしい)
> 二度とソフトウェアの世界に関わらないでもらいたい
作者結構強そうだけど、面と向かってそのセリフ言えんの？
http://en.wikipedia.org/wiki/Brian_Fox_(computer_programmer) [wikipedia.org]
君がbash書いてればbashされることはなかっただろうに残念ですね。
Re:オナニーコーディングの極み (スコア:1)
それでも、Theoなら…
「先 輩 、俺 、喧 嘩 強 い っ す よ ？」
くらい言ってくれるハズ
Re: (スコア:0)
ぜひハードゲ…ウェアに専念してほしい
Re:オナニーコーディングの極み (スコア:2)
子プロセスに関数定義を引き継ぐためのなんだかんだと聞いたような。まあwebからアクセスできるとこで一切bashなんかinvokeしなけりゃいいんですよ。
そんなことをしているつもりの人はごくごくごくごく一部だったんでしょうけど、まあ。
Re: (スコア:0)
そろそろevalじゃなくてevilに名前を変えよう（無理）
Re: (スコア:0)
こういう無謬主義こそソフトウェアの世界で最も忌み嫌われるべきものだと思うんだけど。
石を投げていいのは (スコア:0)
バグを出したことがないやつだけだ。
Re:石を投げていいのは (スコア:1)
正しくは、自分の書いたバグにすぐきづける奴だけ、でないと。
「すぐ」とは「commit する前」
Re: (スコア:0)
なんというか無産・搾取に徹したフリーライダー特有の傲慢さが滲み出てますよね。
Re: (スコア:0, おもしろおかしい)
ライ"ダ"ー？
#プライドすらないという意味ではこれでもあながち間違いではないというのがなんとも。
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:イマイチ理解できないんだけど (スコア: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:イマイチ理解できないんだけど (スコア: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:イマイチ理解できないんだけど (スコア: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)
curl とか rsync とかで 他サーバにデータ渡せないの？
Re: (スコア:0)
"echo vulnerable" は bash が起動された時点で実行されるけど、
関数 () { :; } の中は起動した bash の中でさらに x を実行しないと実行されない。
渡された環境変数名を関数として実行しているとか、任意の環境変数を渡せる
(=本来実行すべきコマンドが環境変数で上書きされる)とかいうことが無ければ
関数の中が実行されることは無いと思う。
Windows以外のOSは致命的な不具合ばかりだなあ (スコア:0, おもしろおかしい)
Windows以外のOSは致命的な不具合ばかりだなあ
Re: (スコア:0)
心配なのは、この脆弱性の影響をモロに受けるLinuxサーバは非常にたくさんあって、かつ、かなりの割合のサーバがアップデートされないまま放置されるであろうということです。
アップデートは難しくないでしょうけれど、それでもアップデートしないサーバ管理者は少なくないでしょう。
Appleのサーバは多くは無いですが、修正パッチすら提供されていませんし。
どうしてこうなった (スコア:0)
・関数を定義できるようにしよう←分かる
・定義した関数をエクスポートできるようにしよう←分かる
・関数のエクスポートは環境変数でやろう←分かる
・環境変数に関数定義っぽいものがあったら全部評価することにしよう←うん……うん？
・評価は全部 eval するようにしよう←おいバカやめろ
shell四天王の中で最弱？ (スコア:0)
最強はzshなのかな
M$製品は危険(笑) (スコア:0, フレームのもと)
OSSなら安全(爆笑)
Re:やっぱり湧いてた (スコア:2)
ニュースになるほど珍しい事例なので完全なパッチがまだなくても安心よかったよかった
Re:M$製品は危険(笑) (スコア:2)
実際安全なわけだが
アンチM$(笑)は捏造が大好き(爆笑)
web serverのユーザーでアクセス? (スコア:0)
bashがweb serverのユーザーでアクセスできるのだとすれば、
apacheをroot で動かしていない限りは、問題は限定的では?
rm -rf / しても全部消えないから始末が悪いとも言えますが。
全ての環境にシェルが入ってるのが以上 (スコア:0)
アンドロイドやクロームにもシェルは必要なんでしょうか？
デスクトップや組み込み、CPUボード搭載のリナックスにはシェルは不要
Systemdにシェルコードが入っていたり、CoreOSのサービス起動にもシェルを使っていたりする
シェル使わずに別の言語で書けば速度も上がっていいのにと某掲示板で書いたらキレラレマシタ
Re:全ての環境にシェルが入ってるのが以上 (スコア:1)
Re:全ての環境にシェルが入ってるのが以上 (スコア:2)
開発者が無限に資源を突っ込んで、機能を変更しない装置については単一の静的リンクバイナリにでもして柔軟性を
一切排除しろというのは理論上可能だけど、それをやった製品はコストがかかりすぎ競争力がないので商業的に失敗する。
理論上安全だけど性能も出なけりゃ使い勝手もクソなので俺も絶対に買いたくない。誰もやらない。
busybox抜きとか、本質的ではないけどbusyboxの一部アプレット抜きくらいは行われている。