パスワードを忘れた? アカウント作成
11597247 journal
日記

90の日記: GNU Bashに脆弱性、環境変数を渡して呼ぶことで任意コード実行が可能に 92

日記 by 90

GNU Bash の脆弱性が公開された。環境変数を経由して関数定義を渡す場合に、細工をしてコマンドを実行させることができる。攻撃に使う環境変数の名前に制限はなく、 sh を呼ぶ CGI に対して HTTP ユーザーエージェントを送る時、 ssh 接続時に環境変数を渡す時など、環境変数を改変した状態で bash が呼ばれれば攻撃ができる。この脆弱性は"すべてのバージョンの bash"にあるとされ、Mac OS Xにも当該のバージョンが含まれるとされている。一部の Linux ディストリビューションではすでに更新を配布している。

Red Hatによると、脆弱性のあるバージョンでは以下の"echo vulnerable"の部分が予期せず実行される。
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

https://access.redhat.com/articles/1200223
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
http://threatpost.com/major-bash-vulnerability-affects-linux-unix-mac-os-x
http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html

日本時間09/25 12:10付で、修正が不十分との補足がされた。CVE-2014-7169ができた。

Update: 2014-09-25 03:10 UTC

Red Hat has become aware that the patch for CVE-2014-6271 is incomplete. An attacker can provide specially-crafted environment variables containing arbitrary commands that will be executed on vulnerable systems under certain conditions. The new issue has been assigned CVE-2014-7169. Red Hat is working on patches in conjunction with the upstream developers as a critical priority. For details on a workaround, please see the FAQ below.
https://access.redhat.com/articles/1200223

09/25 13:00追記: 名前は Heartbleed に続き Shellshock でキマりっぽい?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 例が分かり難い (スコア:5, 参考になる)

    by uxi (5376) on 2014年09月26日 2時25分 (#2682778)

    export HTTP_USER_AGENT='() { :;}; echo dangerous injection'
    bash -c "echo safe code"

    こんな感じで書いてくれれば危険性が分かり易いのになー

    なるほど
    User Agent Switcher で HTTP_USER_AGENT いじって
    CGI で bash 呼んでるサービス閲覧するだけで撃が成立するわけだね。
    確かにこれは怖いわ

    --
    uxi
  • Microsoft大勝利! (スコア:3, おもしろおかしい)

    by Anonymous Coward on 2014年09月25日 16時16分 (#2682387)

    Microsoftはbashという邪悪な危険ソフトウェアを利用しない唯一のソフトウェアです!

  • by Anonymous Coward on 2014年09月25日 15時31分 (#2682373)

    CVE-2014-6271 [redhat.com]のComment 23, 24辺り。

    • by Anonymous Coward on 2014年09月25日 15時48分 (#2682382)

      そこのComment27によるとworkaroundはこちら [redhat.com]
      LD_PRELOADでパッチを読ませるんですって。
      環境変数で出てるバグのパッチを読ませるのに環境変数を使うのってなんだかこそばゆい。

      親コメント
    • 新しい方には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

      親コメント
  • by Anonymous Coward on 2014年09月26日 0時06分 (#2682725)

    https://twitter.com/pascal_gujer/status/515088698892115968 [twitter.com]
    Android 4.4 のbusyboxで出たと言ってる人が居ますね

  • by Anonymous Coward on 2014年09月26日 9時27分 (#2682879)

    A>set s=#{system('notepad')}
    A>ruby -e "printf(\"%s%d\n\", 'aa',1)"

    (Rubyのprintfで勝手にメモ帳が起動される)
    LinuxにできてWindowsにもできないはずがないっ

  • by Anonymous Coward on 2014年09月25日 12時32分 (#2682274)

    Linuxのだと

    $ bash --version
    GNU bash, version 4.2.48(1)-release (x86_64-pc-linux-gnu)
    Copyright (C) 2011 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
     
    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"
    bash: warning: x: ignoring function definition attempt
    bash: error importing function definition for `x'
    this is a test

    こんな感じ。

    Cygwinのだと

    $ bash --version
    GNU bash, version 4.1.11(5)-release (x86_64-unknown-cygwin)
    Copyright (C) 2009 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
     
    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"
    bash: warning: x: ignoring function definition attempt
    bash: error importing function definition for `x'
    this is a test

    こんな感じ。
    違いが全くわからない。
    Cygwinの4.1系でも脆弱性無さげだけど。

    • うちの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 .
      }
      親コメント
    • $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
      vulnerable
      this is a test
      $

      ありだと上のようになるそうです。すべてのバージョンってのが間違ってて、つい最近のものだったりするのか…
      あと修正が不十分だという発言を見かけたのですが、認識された [redhat.com]ようです。

      親コメント
      • by Anonymous Coward on 2014年09月25日 13時41分 (#2682304)

        bash: warning: x: ignoring function definition attempt

        ってのが多分今回のパッチで追加された warning メッセージなので、元コメの人のは既に patch 適用済なのではと思います。

        ディストリビューションに付属のものはバージョン番号を上げずに脆弱性対策のパッチだけを当てることがあるので、バージョン番号のみで判断できないというのはまぁいつものことですね。

        親コメント
    • 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] やってます。
      親コメント
    • by Anonymous Coward

      どっちも対策済みじゃん

  • by Anonymous Coward on 2014年09月25日 16時53分 (#2682405)

    誰だか知りませんが、このバグ作り込んだキチガイは、
    1. 「環境変数に関数埋め込めたら超Coolじゃね?俺って天才!」と思いついて
    2. 関数の解釈を横着するために何が入ってるかもわからないstringをevalする実装を考えついて
    3. それを実装するときにバグを埋め込んで
    4. 世界中のUnix系システムを危険に晒した
    わけですね!

    二度とソフトウェアの世界に関わらないでもらいたい

    • by Anonymous Coward on 2014年09月25日 18時01分 (#2682454)

      > 二度とソフトウェアの世界に関わらないでもらいたい

      作者結構強そうだけど、面と向かってそのセリフ言えんの?
      http://en.wikipedia.org/wiki/Brian_Fox_(computer_programmer) [wikipedia.org]

      君がbash書いてればbashされることはなかっただろうに残念ですね。

      親コメント
    • 子プロセスに関数定義を引き継ぐためのなんだかんだと聞いたような。まあwebからアクセスできるとこで一切bashなんかinvokeしなけりゃいいんですよ。
      そんなことをしているつもりの人はごくごくごくごく一部だったんでしょうけど、まあ。

      親コメント
    • by Anonymous Coward

      そろそろevalじゃなくてevilに名前を変えよう(無理)

    • by Anonymous Coward

      こういう無謬主義こそソフトウェアの世界で最も忌み嫌われるべきものだと思うんだけど。

      • バグを出したことがないやつだけだ。

      • by Anonymous Coward

        なんというか無産・搾取に徹したフリーライダー特有の傲慢さが滲み出てますよね。

        • Re: (スコア:0, おもしろおかしい)

          by Anonymous Coward

          ライ"ダ"ー?

          #プライドすらないという意味ではこれでもあながち間違いではないというのがなんとも。

      • by Anonymous Coward

        間違えるのは仕方ないけど、間違いを重ねることは擁護できません
        1.~3.はそれぞれが超ド級の大間違いで、それが3つも重なったからこんな大騒ぎになってるわけでしょ?

        • by Anonymous Coward

          そんな話じゃない。もっと歴史を勉強すべし。

    • by Anonymous Coward

      ローカル環境で完結するプログラムだと思ってると、無茶な曲芸やっちゃう事もあるかな。

  • by Anonymous Coward on 2014年09月25日 17時36分 (#2682436)

    $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

    ここに echo vulnerable 書き足せるシチュエーションだと
    関数 () { :;} の中も好き放題出来そうな気がするんだけどそれは気のせいなの?

    • by JULY (38066) on 2014年09月25日 18時00分 (#2682452)

      「(){~}」の部分は関数の定義の部分で、その関数定義を環境変数にセットされるところまでは良くて、環境変数にセットされただけだと、誰かがその環境変数に入っている関数を叩かないと実際の処理は発生しない。

      ところが、その直後の「;」の後ろ、関数定義の外側のにある部分を bash が勝手に実行してしまう、というのが今回の脆弱性。

      ...と理解しているけど合ってるかな?

      親コメント
      • by Anonymous Coward

        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側で対処すべき問題だと思います.

          親コメント
        • env echo='() { ls; }' bash -c 'echo hoge'

          他の方のコメントでも書かれていますが、これだと「bash -c」に渡している「echo hoge」の部分を攻撃者が挿入できるか、もしくは、事前に bash 経由で echo を実行する事が分かっている場合になります。前者だと、この問題が無くても外部から任意の実行できることになるので、この脆弱性以前の話だし、後者だと狙った動きをするためには、事前に bash が実行する内容を知っている事が必要、という事になると思います。

          少なくとも、今回の脆弱性があれば、bash が本来実行しようとしている内容にかかわらず、環境変数さえ設定できれば任意のコマンドが実行できます。「-c 'echo hoge'」の部分すら必要ありません。

          ただ、確かに、bash が本来、実行しようとしているコマンドを置き換える事が可能、という点は、条件がそろうと現実的な問題になりうると思います。通常、関数の方が PATH で見つかるコマンドや内部コマンドよりも優先順位が高いですが、環境変数経由で渡ってくる関数も、同様の優先順位で良いのか、という気がします。環境変数経由の関数が通常のコマンドよりも低い優先順位であれば、コマンドの置き換えは避けられるのでは、と思いました。

          親コメント
        • by Anonymous Coward

          その方法で攻撃するためには、攻撃対象が任意の環境変数を渡せるサービスでないとならない。

          攻撃対象が HTTP なら渡せる環境変数は HTTP_USER_AGENT 等に限られるし (多分) 、
          他のサービスでもさすがに任意の環境変数を渡せるようなものは無いのでは。
          (断言はできないけど。)

          • by Anonymous Coward on 2014年09月26日 2時09分 (#2682772)

            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呼び出されてアウトになるわけで、それくらいのことなら私(=趣味でプログラムをいじる程度の人)は余裕でやっちゃってます。怖いよ。このバグ。

            親コメント
          • by Anonymous Coward

            curl とか rsync とかで 他サーバにデータ渡せないの?

    • by Anonymous Coward

      "echo vulnerable" は bash が起動された時点で実行されるけど、
      関数 () { :; } の中は起動した bash の中でさらに x を実行しないと実行されない。

      渡された環境変数名を関数として実行しているとか、任意の環境変数を渡せる
      (=本来実行すべきコマンドが環境変数で上書きされる)とかいうことが無ければ
      関数の中が実行されることは無いと思う。

  • by Anonymous Coward on 2014年09月25日 18時19分 (#2682466)

    Windows以外のOSは致命的な不具合ばかりだなあ

    • by Anonymous Coward

      心配なのは、この脆弱性の影響をモロに受けるLinuxサーバは非常にたくさんあって、かつ、かなりの割合のサーバがアップデートされないまま放置されるであろうということです。

      アップデートは難しくないでしょうけれど、それでもアップデートしないサーバ管理者は少なくないでしょう。

      Appleのサーバは多くは無いですが、修正パッチすら提供されていませんし。

  • by Anonymous Coward on 2014年09月25日 18時30分 (#2682482)

    ・関数を定義できるようにしよう←分かる

    ・定義した関数をエクスポートできるようにしよう←分かる

    ・関数のエクスポートは環境変数でやろう←分かる

    ・環境変数に関数定義っぽいものがあったら全部評価することにしよう←うん……うん?

    ・評価は全部 eval するようにしよう←おいバカやめろ

  • by Anonymous Coward on 2014年09月25日 20時04分 (#2682563)

    最強はzshなのかな

  • M$製品は危険(笑) (スコア:0, フレームのもと)

    by baldmage (45440) on 2014年09月25日 21時54分 (#2682634) 日記

    OSSなら安全(爆笑)

  • by Anonymous Coward on 2014年09月25日 22時19分 (#2682657)

    bashがweb serverのユーザーでアクセスできるのだとすれば、
    apacheをroot で動かしていない限りは、問題は限定的では?
    rm -rf / しても全部消えないから始末が悪いとも言えますが。

  • by Anonymous Coward on 2014年09月26日 0時07分 (#2682726)

    アンドロイドやクロームにもシェルは必要なんでしょうか?
    デスクトップや組み込み、CPUボード搭載のリナックスにはシェルは不要

    Systemdにシェルコードが入っていたり、CoreOSのサービス起動にもシェルを使っていたりする
    シェル使わずに別の言語で書けば速度も上がっていいのにと某掲示板で書いたらキレラレマシタ

    • busyboxのほとんどはashじゃないのかな。Debian系とBSDも起動プロセスはdashやash使ってる。EFI Shellのサンプルコードにもbash入っていたので根は深いと思うけど。
      親コメント
typodupeerror

※ただしPHPを除く -- あるAdmin

読み込み中...