パスワードを忘れた? アカウント作成
12690774 story
セキュリティ

glibcに脆弱性 42

ストーリー by hylom
これは影響がデカい 部門より
あるAnonymous Coward 曰く、

ほぼすべてのLinuxで使われているCライブラリ「glibc」に脆弱性が発見された(ITmedia)。

問題となっているのは、指定したホストのネットワーク的な情報を取得するためのgetaddrinfo関数で、スタックベースのバッファオーバーフローの脆弱性が誘発される可能性があるとのこと。2008年5月にリリースされたglibc 2.9以降のバージョンに存在するという。

また、Google Online Security Blogによると、2048バイトを超すサイズのUDPもしくはTCPレスポンスによって問題が発生するとのこと。迅速なglibcのアップデートおよびそれを利用するアプリケーションの再起動が推奨されているが、それができない場合に向けてファイアウォールなどでレスポンスサイズを制限することで一時的な対象も可能だという。

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

    by Printable is bad. (38668) on 2016年02月18日 2時39分 (#2966400)
    1. 再起動できるサーバの場合の対処方法

      殆どのディストリビューションでは脆弱性が修正された glibc が出てるので、yum update や apt-get update をする。

      CentOS 6.7 でやってみたところ、アップデートが来てました。

      $ sudo yum update

      (略)

      ====================================================================================================
      パッケージ               アーキテクチャ    バージョン                     リポジトリー        容量
      ====================================================================================================
      更新:
      glibc                    x86_64            2.12-1.166.el6_7.7             updates            3.8 M
      glibc-common             x86_64            2.12-1.166.el6_7.7             updates             14 M
      glibc-devel              x86_64            2.12-1.166.el6_7.7             updates            986 k
      glibc-headers            x86_64            2.12-1.166.el6_7.7             updates            615 k

      トランザクションの要約
      ====================================================================================================
      アップグレード       4 パッケージ

      総ダウンロード容量: 20 M
      これでいいですか? [y/N]y

      アップデート後は、glibc を使っているプロセスを全部再起動する必要があるので、可能であるならば OS ごと再起動(reboot)するのが確実です。

      (glibcの脆弱性対策 より引用) [qiita.com]

      どうしても再起動したくない場合は最低限外に通信しそうな sshd, nginx, httpd, php-fpm, mysqld, postgresql-server, postfix, dovecot, sendmail, vsftpd, elasticsearch, node, java, docker, etc, etc… あたりは個別に再起動しといたほうがいいかもねっていうかやっぱ全部だからサーバごと再起動するのが早いね!

    2. glibcのアップデートとサーバの再起動ができない場合の対処方法

      どうしてもすぐにパッチあてや再起動ができないサーバの場合には、glibcの脆弱性対策(取り急ぎiptables/firewalldで叩き落とす!)for CVE-2015-7547 [qiita.com] を参考に、2048バイト以上のDNSレスポンスパケットをUDP/TCP共に廃棄するファイアウォールの設定を速やかに行っておきましょう。

    • by Anonymous Coward

      一時的な対処ですが,
      名前解決に使うDNSサーバ上で,
      2048バイト以上のレスポンスが返らなければ
      とりあえずの対策になるんですかね?

    • by Anonymous Coward

      ディストリのオフィシャルなアップデートが来ないのでiptablesのフィルタを仕掛けてみたら、ちょっと前にほぼ同時に10個くらいひっかかった。
      でも、正しい(けど大きい)レスポンスなのか攻撃なのかよくわからない。保存まではしてないので。
      正規のレスポンスで2048超える事ってよくあるものなんだろうか。

      • by Printable is bad. (38668) on 2016年02月18日 18時48分 (#2966779)

        #2966709
        名前解決に使うDNSサーバ上で,
        2048バイト以上のレスポンスが返らなければ
        とりあえずの対策になるんですかね?

        DNSの通信がそもそも安全性が確保されていないことので、その場合でも成り済まし攻撃は防げません。

        #2966719
        正規のレスポンスで2048超える事ってよくあるものなんだろうか。

        EDNS0 (RFC 2671 の改良版の RFC 6891)の仕様では、

        A good compromise may be the use of an EDNS maximum payload size of 4096 octets as a starting point.

        とあり、BINDなどの実装でもデフォルトで4096オクテットまで対応しているようです。

        TXTレコードに迷惑メール対策の情報・公開鍵など様々なデータを入れるのが一般的になってきているので、2048オクテット以上のDNS応答を廃棄することで、正当な通信も一部阻害されてしまう可能性もあり得ますね。

        なお、glibcの脆弱性対策(取り急ぎiptables/firewalldで叩き落とす!)for CVE-2015-7547 [qiita.com] のはてブコメントでは、

        「長いDNSメッセージは、複数のIPパケットで送るだけなので、iptablesで落とすって無理じゃないの?? / アプリ層のデータを複数のIPパケットで送るのはIPフラグメントとは全然別の処理だよ!」みたいに書かれていましたが、
        DNS では、EDNS0 の仕様により、DNS のプロトコル自体でパケット分割行うことなく(NTPとかとは違う仕様です)、MTU (一般に1454~1500バイト)を超えるパケットの分割は下のレイヤーに任せているわけなので(TCPフォールバックの場合も同様)、
        ファイアウォールにてフラグメント化されたパケットの結合後の容量を制限するか、フラグメント化されたDNS応答パケットを廃棄することで(MTUが2048以上ということは普通無いので)、とりあえずの対策にはなるかと思います。

        親コメント
        • > ファイアウォールにてフラグメント化されたパケットの結合後の容量を制限するか、フラグメント化されたDNS応答パケットを廃棄することで(MTUが2048以上ということは普通無いので)、とりあえずの対策にはなるかと思います。

          ダメです。
          間違った対策を勧めないようにしましょう。
          TCPの場合、そもそも返答が1セグメントに収まってるという保証はありません。
          1つの返答が複数のTCPセグメントに別れて届き、それが2048バイトを越えていたらアウトです。
          ファイアウォールによる上記の制限では、防ぐことはできません。
          実際、
          http://qiita.com/kawaz/items/1b07429b28851f997dba#comme [qiita.com]

          • TCPの場合、そもそも返答が1セグメントに収まってるという保証はありません。
            1つの返答が複数のTCPセグメントに別れて届き、それが2048バイトを越えていたらアウトです。
            ファイアウォールによる上記の制限では、防ぐことはできません。

            ご指摘ありがとうございます。

            「(iptablesで)フラグメント化されたパケットの結合後の容量を制限するか、フラグメント化されたDNS応答パケットを廃棄する」という対策は、UDPによるDNS通信(EDNS0 : RFC 6891 準拠、BIND9以降の初期設定で有効)には有効であっても、TCPフォールバック かつ 複数セグメントへ分割されたTCPパケット の攻撃は防げませんでした。お詫び申し上げます。

            EDNS0(UDP)の場合は大きなデータの場合には、必ず IPフラグメンテーションが発生するので、iptables で制御可能です。

            しかし、ご指摘いただいたとおり、TCPフォールバックの場合、TCPでは通信の効率化のために Maximum Segment Size(1452~1460バイトな場合が多い)ごとのセグメントに分割され、IPフラグメンテーションが発生しない2セグメントのTCPパケットとなることがあります。その場合、iptables で結合後のデータサイズをチェックしても複数セグメントの合算が行われない仕様となっているため(またフラグメンテーションされたIPパケットともみなされないため)、iptables では、TCPフォールバック かつ 複数セグメントへ分割されたTCPパケット による攻撃(2048バイト以上のDNS応答を受信してしまう)は防げませんでした。

            iptables でこの攻撃を防ぐとしたら、TCPによるDNS通信を廃棄(TCPフォールバックの無効化)するしか無いようです。その場合であっても、TCPフォールバックは非効率(遅延に繋がる)であることからBIND9以降はEDNS0 がデフォルト有効なので問題が生じない場合も多いですが、EDNS0に対応していないサーバとの通信の場合には512 バイトを超える DNS メッセージを受信できなくなってしまうためTXTレコードの取得などの正常な通信にも影響が出てしまいます。弊害なく iptables のみで対策するのは不可能なようです。

            親コメント
  • by KuroButa (37060) on 2016年02月17日 22時37分 (#2966336) 日記

    今、アップデート確認したら125個も来てた。
    こりゃ、再起動コースかな・・・

  • by Artane. (1042) on 2016年02月17日 19時23分 (#2966257) ホームページ 日記

    sidにはパッチが当たったlibcが下りて来てますが、stretch(testing)はまだ。
    http://metadata.ftp-master.debian.org/changelogs/main/g/glibc/glibc_2.... [debian.org]より:

    glibc (2.21-8) unstable; urgency=critical

        * Update from upstream stable branch:
            - Fix an integer overflow in hcreate() and hcreate_r() (CVE-2015-8778).
                Closes: #812441.
        * patches/any/local-CVE-2015-7547.diff: new patch to fix glibc getaddrinfo
            stack-based buffer overflow (CVE-2015-7547).

      -- Aurelien Jarno Mon, 15 Feb 2016 21:38:15 +0100

    多分、jessieやwheezyには降りてて、sqeeze-ltsはよくわからない(まだかも)。

    --
    --暮らしの中に修行あり。
    blogはじめました。 [hatena.ne.jp]
    • Re:Debianだと (スコア:5, 参考になる)

      by annoymouse coward (11178) on 2016年02月17日 19時40分 (#2966262) 日記

      jessie つまり stable も修正済みです

      DSAから引用すると
      > For the stable distribution (jessie), these problems have been fixed in version 2.19-18+deb8u3.
      とのことです

      なおglibcにはCVE-2015-7547だけでなく,さらに3つ脆弱性が発見されていて,今回のアップデートで修正されているとのことです

      詳細は https://www.debian.org/security/2016/dsa-3481 [debian.org] をみてください

      親コメント
      • by Anonymous Coward

        発見者がFedoraの開発者であることもあってGentooなどのマイナーなディストリビューションを除いて主要なディストリビューションは既に修正済みのようですね。

        • by Anonymous Coward on 2016年02月17日 21時24分 (#2966296)

          発見者がFedoraの開発者であることもあってGentooなどのマイナーなディストリビューションを除いて主要なディストリビューションは既に修正済みのようですね。

          何を勘違いしてるのか知らんが、あらゆるディストリに先駆けて速攻で対策したのがGentooですから。
          glibc-2.22用がこれ [gentoo.org]。 (2016-02-16 20:38:22)
          glibc-2.21用がこれ [gentoo.org]。 (2016-02-16 19:01:28)
          とっくの昔にrsync配布止めてるんで、.ebuildが書かれた瞬間にgithubからemerge --syncで一発で落ちてくるやね。

          ええ。ビルドは各自勝手にするから、パッチ書くだけなんで速攻ですよ。
          スラドのタレコミどころか、ITmediaの記事が出るより早いみたいなね。
          そもそもこの速度に主要なディストリビューションとやらが着いてこれるわけねえじゃん。
          むしろ何故Gentooがまだだと思ったのか理解できない・・・

          つーか俺もそうだったけど、気が早い奴はportageで降ってくる前にepatch_userで勝手にパッチ当ててリビルドしてたんでねえの?
          matsuu@厳冬あたりだったらepatch_userどころか、自分で.ebuildまで書いてmergeしてそうだし。
          だいたいからして、他人が握ったライブラリ使うだけの輩と一緒くたにされたくはねえわな。

          親コメント
          • debian のリポジトリは 2016-01-31 に修正されています
            https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?id=a398029... [debian.org]

            そもそも CVE-2015 とあるようにこれは去年見つかったバグで,具体的には2015年の7月に報告されたものです
            https://sourceware.org/bugzilla/show_bug.cgi?id=18665 [sourceware.org]

            bugzillaにやり取りが記録されていますが,問題が指摘されてから修正されるまでに半年近く掛かっています.
            つまり glibcの開発者やディストリビューションのメンテナ達は半年前から原因究明,修正作業を進めていた事になります

            この全体の工程をみれば,アップデートの配布日が数日前後するのは些細なことですし
            その数日の差で一喜一憂するのは末端の一部のユーザだけだと思います

            親コメント
            • by Anonymous Coward

              > bugzillaにやり取りが記録されていますが,問題が指摘されてから修正されるまでに半年近く掛かっています.
              > つまり glibcの開発者やディストリビューションのメンテナ達は半年前から原因究明,修正作業を進めていた事になります

              というよりも、実際に攻撃が成立する手法がなさそうな間は対処の優先順位が低かっただけでしょ
              実際に手法が確立してこりゃやばいとなったから一気に修正しなきゃになっただけで

              • by Anonymous Coward

                そうそう。

                • redhatは早期に発見し、根治のため時間をかけていた
                • googleが後から発見し、表面的な修正策とともに連絡をとった
                • 合同で攻撃手法を研究し発見、根本解決を発表←今ココ

                みたいな順序じゃなかったっけ

            • bugzillaにやり取りが記録されていますが,問題が指摘されてから修正されるまでに半年近く掛かっています.
              つまり glibcの開発者やディストリビューションのメンテナ達は半年前から原因究明,修正作業を進めていた事になります

              邪悪なM$()が修正に半年もかけてたら
              鬼の首でも取ったかのように大騒ぎするくせに

              • by Anonymous Coward

                え、普通に半年以上放置してから出てきているものもありますよね?

                exploitが出てから影響範囲と期間のバランスなんじゃないの? ユーザの手元にウイルスが届いているのにパッチがない状態だったら 普通に怒ると思いますが、今回はそうじゃないでしょ・・・

                相変わらず、信者はどこの信者も気持ち悪いね

              • by Anonymous Coward

                お互いを信者と罵り合い、結局誰も何かに陶酔しているわけではないという…

          • by Anonymous Coward

            Gentooのパッケージシステムってそんな感じなのか、めっちゃ面白そう。
            Archだと公式/準公式レポのビルド設定が気に食わない事が多くて、どうせmakepkgしちゃうんだよなぁ。

            • by Anonymous Coward

              /etc/portage/make.confにいろいろ書いておけば、あとは全部ソースからビルドしてくれるよ。これが標準。libreOfficeとかデカいのは、バイナリパッケージというのも可。

              #たぶんArchでも同じようにできるのだろうけど、デフォルトがバイナリかソースからビルドかの違いなんかな?Archもちょっと使ってみたい。

          • by Anonymous Coward

            https://bugs.gentoo.org/show_bug.cgi?id=574880 [gentoo.org]
            ここのcomment2

            pre-notification channelsを持ってないのがマイナーな鳥

          • by Anonymous Coward

            Gentooって他のディストリビューションでも使えるコードを書いたりもせず、セキュリティの調査に参加したりもせず、ただ配布のみを行ってる印象でRedHatとは対照的。

            「ライブラリを握るだけ」のディストリビューションなんですよね。

            • by Anonymous Coward

              Gentoo は成果を upstream に持ってこうとせずに
              ディストリビューションの閉じた世界の中で
              黒魔術を駆使しまくるイメージ。

          • by Anonymous Coward

            とりあえず、、、

            「そうだ、そうだ」

            #遠山の金さんのおしらすの雑魚悪役風

  • 去年の7月のやつじゃないか。
    何を今更記事にしてるんだ?

    • by Anonymous Coward

      よくわかってないんだけど、去年の7月のやつとは何が変わったんだろう?
      攻撃対象が増えた? 前回は暫定対処だけで、根本解決のパッチがやっと出た?

  • by Anonymous Coward on 2016年02月17日 19時23分 (#2966256)

    「一時的な対処」では?

    • by Anonymous Coward

      誰だい、このバグを仕込んだのは?

      • by Anonymous Coward

        バグじゃないよ、仕様だよ

        • by Anonymous Coward

          なら仕様が間違っていると上に突き返そう。

          #それが出来たら苦労しないのでAC

  • by Anonymous Coward on 2016年02月17日 20時22分 (#2966271)

    関連ストーリーに挙がっているgethostbyname()の脆弱性への対策では「getaddrinfo()使えば大丈夫!」なんてサジェストしてたみたいですが…こっちもダメだったんじゃねーか!
    http://linux.srad.jp/comments.pl?sid=650658&cid=2751734 [linux.srad.jp]

  • by Anonymous Coward on 2016年02月17日 22時13分 (#2966325)

    glibcのgetaddrinfo関数使ってたらアウト?

  • by Anonymous Coward on 2016年02月18日 10時12分 (#2966509)

    Androidやアプライアンスも中開けてみたらLinuxだったりしませんか?glibc使っていないといいけども…

    • by Anonymous Coward

      AndroidはカーネルはLinuxですが、libcはbionic libcという独自のものを使ってます。
      アプライアンス系は、規模の小さいものだとuclibcとかnewlibなどにしている場合もありますが、普通にglibcをそのまま使っているのもありそうですね。

  • by Anonymous Coward on 2016年02月18日 13時53分 (#2966610)

    初のlinuxプロジェクトで、とあるソフトのバグ調査してて、ソース見たら一つの名前/アドレスが必ず来る前提で組まれてた奴見たとき絶句。

    ゼロも二つ以上もダメというね。。
    Winと違って~とかドヤ顔も印象深い。

    もう10年位前だが、あそこの考え方からすると今もそのままだろうな。

    • by Anonymous Coward

      日本語でおk

      • by Anonymous Coward

        初のりなっくす計画で、柔らかの虫調査してて、西洋風醤油見たら一つの名前/住所が必ず来る前提で組まれてた奴見たとき絶句。

    • by Anonymous Coward
      コーディングはみんなで成すものだから、お客様態度で使う人間にとってはそりゃあ違和感があるよね…
typodupeerror

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー

読み込み中...