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はまだなのかな...