パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

TCP仕様の1つに中間者攻撃可能な脆弱性、Linuxが影響を受ける」記事へのコメント

  • リンク先など (スコア:5, 参考になる)

    by ogino (1668) on 2016年08月18日 8時54分 (#3065301) 日記

    とりあえず CVE-2016-5696 [mitre.org] についての幾つかのディストリビューションへのリンク

    Debian [debian.org] ほとんど全部?
    Ubuntu [canonical.com] デフォルトのパッケージだとほぼ全部?
    RHEL/CentOS [redhat.com] 6/7, MRG 2
    SUSE [suse.com] 12, 11 SP3 and SP4

    Register のリンク先ではワークアラウンドとして tcp_challenge_ack_limit に大きい値を設定するというのが紹介されています。999999999 の箇所は Akamai blog [akamai.com] では 1073741823になっています。大きければ良さそう。(デフォルトは 100?)

    As a workaround while patches to fix the problem are prepared and distributed, you can raise the rate limit on your Linux machine or gadget so that it cannot be reached, by appending the following to /etc/sysctl.conf:

        net.ipv4.tcp_challenge_ack_limit = 999999999

    And then use sysctl -p to activate the new rule. You need to be root to do this.

    「RFC 5961に重大な脆弱性が発見され」とあるけれど、「LinuxカーネルのTCP実装にセキュリティホール」「LinuxカーネルにおけるTCPスタック実装の脆弱性」など、実装に脆弱性が見つかったという表現しか見つかりません。どっちでしょう。

    • Re:リンク先など (スコア:4, 参考になる)

      by Anonymous Coward on 2016年08月18日 9時36分 (#3065323)

      RFCの方を見るとErrata Existsとあるので検索したら出てきました。
      https://www.rfc-editor.org/errata_search.php?rfc=5961 [rfc-editor.org]

      Section 7 says:

      [The entire section]

      It should say:

      No suggested text because it requires a much more serious analysis.
      May be adding that the rate-limit counter SHOULD be per-connection,
      in the spirit of RFC 6528?

      第7項の以下の内容:

      [項全体]

      この内容の訂正:

      もっと精密な調査が必要なため提案できる文章はない。rate-limitカウンタへの加算はRFC 6528でされているように接続ごとにすべき (SHOULD) かもしれない。

      Notes:

      It appears the section does not specify that the counter for ACK throttling SHOULD be per-connection. In Linux, it is apparently global, which allowed its use as a side channel enabling nasty attacks (CVE-2016-5696 and the paper "Off-Path TCP Exploits: Global Rate Limit Considered Dangerous" )

      注記:

      当該セクションはACK throttlingのためのカウンタは接続ごとにされるべき (SHOULD) であることを規定していないようである。Linuxでは、どうやらグローバルになっていて、悪意のある攻撃を可能にするサイドチャネル攻撃を許してしまう。 (CVE-2016-5696と論文"Off-Path TCP Exploits: Global Rate Limit Considered Dangerous" より)

      RFC 5961での記述漏れが脆弱な実装を許してしまったようですね。こんなの実装すればすぐ気づけるように思えますが、人間は間違えるものですしね。

      親コメント
      • by Anonymous Coward

        DNS関係見てたときに思ったことだけど、どっちの方向にブレるかは、文化というか各OSでのRFCに対する考え方次第に感じるなあ。

        なので私はBINDは自宅で使わない。

    • by Anonymous Coward on 2016年08月18日 15時51分 (#3065491)

      Ubuntu(14.4LTS)はさっきアップデートがかかってきましたよ。
      Changelog見る限り3.13.0-95 #142で修正した模様。

      Debianはまだなのかな...

      親コメント
  • 問題はAndroidか (スコア:2, 参考になる)

    by Anonymous Coward on 2016年08月18日 12時48分 (#3065404)

    Googleの修正パッチ提供が最速で9月、ベンダパッチはそれより後か。きっついなあ。

    Linux向けの修正プログラムは7月11日にすでに提供されているが、この脆弱性の影響を受けるAndroid向けには未提供のままだ。
    Android 4.4以降の端末は、Android開発者向けサイトによれば8月1日現在で全Android端末の79.9%を占めており、
    現在開発者向けプレビューが提供されているAndroid 7.0 Nougatも対象となっている。

    Lookoutでは、9月にGoogleより配信されるAndroid向けの月例セキュリティアップデートでこの問題が修正されることを期待すると述べている。

    • by Anonymous Coward
      自分の場合は、カスタムカーネル使ってるので、パッチあたったのは先月には出てきてるな。

      Android 全般はともかく、カスタムしてない人でも Galaxy系なら毎月セキュリティアップデートが配信されてるでしょ。
      今月のアップデートには入ってなかったようだけど、来月のアップデートには入るんじゃないの?
      • by Anonymous Coward

        Galaxyすごいな。LGだけど、最後のアップデートが2016/1/14だ。

        • by Anonymous Coward
          もともと2、3ヶ月に1回ぐらいの不定期なアップーデートは Sと Note シリーズ向けにはやってたので、運用実績が長いからね。
          セキュリティ更新やる枠組みとしては、端末も配信サーバーも整ってたところに、Google が月例更新に決めたので Samsung も月例にしたってことぐらいしか変わってない。
          • by Anonymous Coward

            Android自体に更新の仕組みがあるんだから、端末の対応や配信サーバーの用意はどこでもあるでしょう。
            LGだって配布そのものは自動だし。

            おそらく大変なのは、headへの追従と動作テストでは。Samsungはその辺の体制ができてるんでしょうね。

            • by Anonymous Coward
              Samsung の セキュリティアップデートって、Android の更新の仕組みじゃないでしょ。
              Samsung 独自の KNOX って奴。

              再起動とかいらないから、ユーザーが使ってても裏で更新するし、国やキャリアにも関係なく Galaxy 使ってればセキュリティの更新だけ Samsung からやってくる。利用者は基本的に気付かない。
              Google も Nexus で同じことをやろうとはじめたけど Nexus は既存の OTA でやろうとしてるから再起動するし recovery が見えちゃうんだよな。
              • by Anonymous Coward

                TCPのプロトコルスタックの差し替えだから
                再起動は必須では?

              • by Anonymous Coward
                どうなんだろうねぇ。
                カーネルのパッチでも今までだと再起動不要だったから、カーネルレベルのパッチでも動的にあてる仕組みはあるっぽい。kpatch と同じかどうかは知らんけど。
                実現方法はわからんからTCPスタックでも出来る範囲なのかどうかはわからんけど。
  • by Anonymous Coward on 2016年08月18日 10時56分 (#3065355)

    >FreeBSDなどのLinux以外のOSではRFC 5961の実装が遅れていた
    4月1日に出たRFCならFreeBSDで実装が遅れるなんて事はありえないのに・・・

    • by Anonymous Coward

      つまり全て(可能な限り)のRFCは年一回4月1日に発行すればいいのか

    • by Anonymous Coward

      >FreeBSDなどのLinux以外のOSではRFC 5961の実装が遅れていた
      4月1日に出たRFCならFreeBSDで実装が遅れるなんて事はありえないのに・・・

      RFC の著者見ると Cisco で Randall Stewart さんがいますね。
      ということは、FreeBSD で実装されてないとはとても思えないのが。
      実は実装の方が RFC の先を行ってた可能性が高い。

  • by Anonymous Coward on 2016年08月18日 10時58分 (#3065356)

    平文のTCPであれば、今回の件とは無関係に中間者は何でもできる。
    暗号化されていれば、今回の件があっても中間者は改竄できない。

    通信経路上にいる中間者ではなく、経路上にいない無関係者が攻撃できる、というのがこの脆弱性。

  • by Anonymous Coward on 2016年08月18日 11時11分 (#3065365)

    ましてや8/16に4.7.1が出ているというのに、あたかも未だ未修正であるかの如く書かれた邦訳をあえて選択しタレコミ
    その部分を修正するのが仕事であるhylomも、いつものように安定のスルー

    さすがスラド
    低レベル極まりない

    • by Anonymous Coward on 2016年08月18日 12時34分 (#3065395)

      >この脆弱性がAndroid 4.4以降にも存在することが報じられている

      これが本旨でしょ。ソースも8月10日以降の記事で、遅すぎるということもない。
      タイトルが悪いな。

      親コメント
    • 中身、リンク先は妥当だと思うけど。

    • by Anonymous Coward

      いずれの日本語記事にもカーネルには修正パッチが提供されているとあり、一方には7/11と日付もあるが、何か不満なのか

      • by Anonymous Coward

        ここで記事になった時点でもうパッチだけじゃなく本体に入ってるよ、と言いたいのでは。

    • 今までWindows向けのセキュリティパッチが公開された時も
      「Windowsはこんなにも危険!」って煽ってきたんだけどね

      • by Anonymous Coward

        大甘です。Debianは毎日のようにセキュリティ修正版パッケージがリリースされています。
        https://www.debian.org/security/ [debian.org]

        OSのバグの数ならWindowsは周回遅れもいいところでしょう。

        # ヒント: Debianは数万の公式パッケージがOSの一部として扱われている

        • by Anonymous Coward
          セキュリティリスクの報告は昔から Windows より Linux のほうが圧倒的に多いのだから、セキュリティ修正が多いのは当たり前。
          公式パッケージの数とか関係ない。
          • by Anonymous Coward

            公式パッケージの数が多いとセキリティリスクの報告数も増えますよ

    • by Anonymous Coward

      「未だ未修正」

      • by Anonymous Coward

        みだひつじしゅうせい

最初のバージョンは常に打ち捨てられる。

処理中...