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.
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?
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" より)
リンク先など (スコア:5, 参考になる)
とりあえず 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?)
「RFC 5961に重大な脆弱性が発見され」とあるけれど、「LinuxカーネルのTCP実装にセキュリティホール」「LinuxカーネルにおけるTCPスタック実装の脆弱性」など、実装に脆弱性が見つかったという表現しか見つかりません。どっちでしょう。
Re:リンク先など (スコア:4, 参考になる)
RFCの方を見るとErrata Existsとあるので検索したら出てきました。
https://www.rfc-editor.org/errata_search.php?rfc=5961 [rfc-editor.org]
RFC 5961での記述漏れが脆弱な実装を許してしまったようですね。こんなの実装すればすぐ気づけるように思えますが、人間は間違えるものですしね。
Re: (スコア:0)
DNS関係見てたときに思ったことだけど、どっちの方向にブレるかは、文化というか各OSでのRFCに対する考え方次第に感じるなあ。
なので私はBINDは自宅で使わない。
Re:リンク先など (スコア:1)
Ubuntu(14.4LTS)はさっきアップデートがかかってきましたよ。
Changelog見る限り3.13.0-95 #142で修正した模様。
Debianはまだなのかな...
問題はAndroidか (スコア:2, 参考になる)
Googleの修正パッチ提供が最速で9月、ベンダパッチはそれより後か。きっついなあ。
Linux向けの修正プログラムは7月11日にすでに提供されているが、この脆弱性の影響を受けるAndroid向けには未提供のままだ。
Android 4.4以降の端末は、Android開発者向けサイトによれば8月1日現在で全Android端末の79.9%を占めており、
現在開発者向けプレビューが提供されているAndroid 7.0 Nougatも対象となっている。
Lookoutでは、9月にGoogleより配信されるAndroid向けの月例セキュリティアップデートでこの問題が修正されることを期待すると述べている。
Re: (スコア:0)
Android 全般はともかく、カスタムしてない人でも Galaxy系なら毎月セキュリティアップデートが配信されてるでしょ。
今月のアップデートには入ってなかったようだけど、来月のアップデートには入るんじゃないの?
Re: (スコア:0)
Galaxyすごいな。LGだけど、最後のアップデートが2016/1/14だ。
Re: (スコア:0)
セキュリティ更新やる枠組みとしては、端末も配信サーバーも整ってたところに、Google が月例更新に決めたので Samsung も月例にしたってことぐらいしか変わってない。
Re: (スコア:0)
Android自体に更新の仕組みがあるんだから、端末の対応や配信サーバーの用意はどこでもあるでしょう。
LGだって配布そのものは自動だし。
おそらく大変なのは、headへの追従と動作テストでは。Samsungはその辺の体制ができてるんでしょうね。
Re: (スコア:0)
Samsung 独自の KNOX って奴。
再起動とかいらないから、ユーザーが使ってても裏で更新するし、国やキャリアにも関係なく Galaxy 使ってればセキュリティの更新だけ Samsung からやってくる。利用者は基本的に気付かない。
Google も Nexus で同じことをやろうとはじめたけど Nexus は既存の OTA でやろうとしてるから再起動するし recovery が見えちゃうんだよな。
Re: (スコア:0)
TCPのプロトコルスタックの差し替えだから
再起動は必須では?
Re: (スコア:0)
カーネルのパッチでも今までだと再起動不要だったから、カーネルレベルのパッチでも動的にあてる仕組みはあるっぽい。kpatch と同じかどうかは知らんけど。
実現方法はわからんからTCPスタックでも出来る範囲なのかどうかはわからんけど。
8月じゃ仕方がない (スコア:1)
>FreeBSDなどのLinux以外のOSではRFC 5961の実装が遅れていた
4月1日に出たRFCならFreeBSDで実装が遅れるなんて事はありえないのに・・・
Re: (スコア:0)
つまり全て(可能な限り)のRFCは年一回4月1日に発行すればいいのか
Re: (スコア:0)
>FreeBSDなどのLinux以外のOSではRFC 5961の実装が遅れていた
4月1日に出たRFCならFreeBSDで実装が遅れるなんて事はありえないのに・・・
RFC の著者見ると Cisco で Randall Stewart さんがいますね。
ということは、FreeBSD で実装されてないとはとても思えないのが。
実は実装の方が RFC の先を行ってた可能性が高い。
中間者攻撃ではない (スコア:1)
平文のTCPであれば、今回の件とは無関係に中間者は何でもできる。
暗号化されていれば、今回の件があっても中間者は改竄できない。
通信経路上にいる中間者ではなく、経路上にいない無関係者が攻撃できる、というのがこの脆弱性。
7/24の4.7.0で既に修正済 (スコア:0)
ましてや8/16に4.7.1が出ているというのに、あたかも未だ未修正であるかの如く書かれた邦訳をあえて選択しタレコミ
その部分を修正するのが仕事であるhylomも、いつものように安定のスルー
さすがスラド
低レベル極まりない
Re:7/24の4.7.0で既に修正済 (スコア:1)
>この脆弱性がAndroid 4.4以降にも存在することが報じられている
これが本旨でしょ。ソースも8月10日以降の記事で、遅すぎるということもない。
タイトルが悪いな。
タイトルが悪いだけ? (スコア:0)
中身、リンク先は妥当だと思うけど。
Re: (スコア:0)
いずれの日本語記事にもカーネルには修正パッチが提供されているとあり、一方には7/11と日付もあるが、何か不満なのか
Re: (スコア:0)
ここで記事になった時点でもうパッチだけじゃなく本体に入ってるよ、と言いたいのでは。
ようやくLinuxがWindowsに追いついてきた (スコア:0)
今までWindows向けのセキュリティパッチが公開された時も
「Windowsはこんなにも危険!」って煽ってきたんだけどね
Re: (スコア:0)
大甘です。Debianは毎日のようにセキュリティ修正版パッケージがリリースされています。
https://www.debian.org/security/ [debian.org]
OSのバグの数ならWindowsは周回遅れもいいところでしょう。
# ヒント: Debianは数万の公式パッケージがOSの一部として扱われている
Re: (スコア:0)
公式パッケージの数とか関係ない。
Re: (スコア:0)
公式パッケージの数が多いとセキリティリスクの報告数も増えますよ
Re: (スコア:0)
「未だ未修正」
Re: (スコア:0)
みだひつじしゅうせい
Re: (スコア:0)
殿子と(ボソッ
どう言い換える? (スコア:0)
「んだってさ」「らしいッス」
Re: (スコア:0)
「~らしいで、知らんけど」
提供されたらこう書け (スコア:0)
Re: (スコア:0)
伝聞であると言う事を明示するのが悪いとでも?
Re:「とのこと」「とのこと」うるせえーーー (スコア:1)
文法の規範には適っていても文体が「そして」を多用するルカ福音書みたいだ、
洗練から程遠いまま垂れ流しという否定的評価なのかなあ。
あるいは(動詞句連体形の直後で)「由」1文字、(名詞句の直後で)「の由」2文字
と言い換え可能だから漢字使って文字数削減欲しかったんじゃないでしょうか?
中学生の校内新聞を引き合いに出す語り口から謎は深まるばかり。