下記投稿の私家版翻訳です。
http://lists.infradead.org/pipermail/hostap/2018-August/038749.html
脆弱性の内容ではなく対策だけ知りたい場合は一番下の「可能な対策」を見てください。
脆弱性の内容
wpa_supplicant の EAPOL-Key フレーム処理にて脆弱性が見つかりました。この脆弱性により攻撃者はフレームを改変することができます。これによりwpa_supplicantは妥当なMICが無いフレームであっても復号化してしまいます。つまり認証されていないフレームということです。この問題は WPA2/RSN においてユニキャスト暗号方式に TKIP を使用した場合に発生します。WPA2 はユニキャスト暗号方式に TKIP を使用することを想定しておらず、 CCMP を使用することが想定されています。そのため、この脆弱性は実際の運用では起こりません。（訳注:WPA2の初期の段階ではユニキャスト暗号方式に TKIP が認められており、その後禁止されました。ですのでその間に発売されたアクセスポイントのユーザーはこの脆弱性の影響を受けます。）
ユニキャスト暗号方式として TKIP が選択された場合、 EAPOL-Key フレームの Key Data field は RC4 を用いて暗号化されます。この脆弱性は認証されていない EAPOL-Key フレームが処理されることを許可します。また、 RC4 の設計により、攻撃者が Key Data field のプレインテキストバージョンを改変することを許可します。この時攻撃者はビットごとのXORを用い、中身を知る必要はありません。これによりステーションの GTK/IGTK を改変することで DOS 攻撃を行うことができます。この時攻撃者は鍵について知る必要はありません。この攻撃によりステーションはグループアドレス宛のフレームを受信できなくなります。さらに言えば、この攻撃で wpa_supplicant を復号オラクル（訳注:暗号化されたデータを復号化してくれるもの）として使用することができます。これによりグループ暗号キーを得るために GTK/IGTK の Key Data ペイロードを復元する試行が可能です。
グループ暗号キーの完全な復元のためには複数の試行（1オクテットあたり128回の接続試行）が必要です。それらの試行は 4-way handshake の失敗により切断されます。これらの失敗により、アクセスポイントやネットワークは一時的あるいは恒久的（有効にするにはユーザーのアクションが必要）に使用不可能になります。つまり、 AP がグループ暗号キーを変更する前にそれを解析するのは実質的には不可能ということです。デフォルトでは wpa_supplicant は接続試行の失敗の都度最低10秒待つことになっています。言い換えれば各オクテットを復元するために20分待つことになります。ただし、hostapdはTKIPを使用した場合、デフォルトでは10分でキーの更新を行います。つまり、実際的な攻撃のためには、大量のステーションが必要になります。
脆弱性のあるバージョン/設定
全てのバージョンの wpa_supplicant。
謝辞
この問題の発見と報告について imec-DistriNet research group of KU Leuven の Mathy Vanhoef に感謝します。
可能な対策
- RSN/WPA2 においてユニキャスト暗号方式から TKIP を削除します。これはアクセスポイント側でも対応できます。
- 下記のパッチを適用して wpa_supplicant をビルドします。
"WPA: Ignore unauthenticated encrypted EAPOL-Key data" https://w1.fi/security/2018-1
- リリースされたら、 wpa_supplicant v2.7 以上にアップデートします（訳注:2018/08/09時点ではまだリリースされていません）。