TCP SACK パニック - カーネルの脆弱性 - CVE-2019-11477、CVE-2019-11478、および CVE-2019-11479

概要

Linux カーネルによる TCP ネットワーキングの処理で、関連する 3 つの不具合が見つかりました。  最も深刻な脆弱性の場合、リモートの攻撃者は影響を受けるソフトウェアを実行しているシステムでカーネルパニックを引き起こすことができ、その結果、システムの可用性に影響します。

この問題には複数の CVE が割り当てられました。CVE-2019-11477 の重大度は 重要な影響 と判断され、CVE-2019-11478 および CVE-2019-11479 は 中程度の影響 と判断されました。 

そのうちの 2 つは、MSS (最大セグメントサイズ、Maximum Segment Size) と SACK (選択的確認応答、Selective Acknowledgement) パケットが関連する不具合で、3 つ目の不具合は MSS のみに関連します。

これらの問題は、軽減策またはカーネルパッチを適用して修正されます。  軽減策の詳細と RHSA アドバイザリーへのリンクは、「解決策」タブを参照してください。

問題の詳細と背景情報

関連する 3 つの不具合は、サイズの小さい MSS を扱う TCP の SACK (選択的確認応答、Selective Acknowledgement) パケットに対する Linux カーネルの処理で発見されました。現時点では、影響の範囲はサービス拒否 (DoS) に限定されると見られています。現在、特権の昇格や情報漏えいの疑いはありません。

この記事に記載されている軽減策を使用することができますが、低い値の MSS を必要とする正当なソースからトラフィックを適切に送信できなくなる可能性があり、システムのパフォーマンスに影響する可能性があります。システムの環境に適する軽減策を判断してから、軽減策を適用してください。

SACK とは

TCP の SACK (選択的確認応答、selective acknowledgement) とは、正常に受け入れられたすべてのセグメントに関して、データの受信側が送信側に通知できる仕組みのことです。これにより、送信側は「既知の適切な」セットに欠けているストリームのセグメントを再送信することができます。TCP の SACK が無効である場合、完全なストリームを再送信するには、はるかに大きな再送信のセットが必要になります。

MSS とは 

MSS (最大セグメントサイズ、maximum segment size) とは、再構築された TCP セグメントに含まれるデータの合計量を指定するパケットの TCP ヘッダーのパラメーターセットです。
パケットが異なるルートで送信されると、断片化される可能性があるため、ホストが処理可能な最大 IP データグラムペイロードサイズと同じ値を MSS として指定する必要があります。MSS の値が大きすぎると、宛先に送信される途中でパケットのストリームが断片化される可能性があります。逆に、パケットが小さいと断片化の可能性は低くなりますが、未使用のオーバヘッドが発生します。

オペレーティングシステムおよびトランスポートとタイプは指定の MSS の値をデフォルトとすることができます。アクセス権限を持つ攻撃者は、パケットの改ざんされた MSS オプションを使用して raw パケットを作成し、この攻撃を実行することができます。

TCP の SACK

TCP はコネクション指向のプロトコルです。2 者が TCP 接続上で通信を行う場合、特定の情報を交換して接続を確立します。この情報には、接続開始の要求 (SYN)、初期シーケンス番号、確認応答番号、接続上で使用する MSS (最大セグメントサイズ、maximum segment size)、SACK (選択的確認応答) を送信および処理するパーミションなどが含まれます。この接続確立プロセスは、3 ウェイハンドシェイクと呼ばれます。

TCP は、セグメントと呼ばれる単位でユーザーデータを送受信します。TCP セグメントは TCP ヘッダー、オプション、およびユーザーデータで構成されます。
​

各 TCP セグメントには SEQ (シーケンス番号、sequence number) と ACK (確認応答番号、acknowledgement number) があります。

これらの SEQ および ACK 番号は、受信側によって正常に受信されたセグメントを追跡するために使用されます。ACK 番号は、受信側が想定する次のセグメントを示します。

例: 上記でユーザー「A」はそれぞれが 100 バイトの 13 個のセグメントで 1 キロバイトのデータを送信します。これは各セグメントの TCP ヘッダーが 20 バイトであるため 13 個になります。受信側では、ユーザー「B」が 1、2、4、6 番のセグメントと 8 から 13 番のセグメントを受信します。3、5、7 番のセグメントは失われ、ユーザー「B」によって受信されません。

ユーザー「B」は ACK 番号を使用して、3 番のセグメントを次に想定していることを示します。これにより、ユーザー「A」は 2 番よりも後のセグメントはすべてユーザー「B」によって受信されていないと解釈します。4、6 番のセグメントと 8 から 13 番のセグメントはユーザー「B」が正常に受信したにも関わらず、ユーザー「A」は 3 番以降のセグメントをすべて再送信します。ユーザー「B」は 3 番以降に受信したセグメントがあることをユーザー「A」に示すことはできません。これにより、ネットワークが非効率に使用されることになります。

SACK (選択的確認応答)

SACK では、ユーザー「B」は TCP オプションフィールドを使用して、正常に受信したすべてのセグメント (1、2、4、6 および 8-13) をユーザー「A」に通知します。そのため、ユーザー「A」は 3、5、および 7 番のセグメントのみを再送信する必要があるため、ネットワークの帯域幅を大幅に節約し、輻輳を回避することができます。

CVE-2019-11477 SACK パニック
SKB (ソケットバッファー):
SKB (ソケットバッファー) は、Linux の TCP/IP 実装で使用される最も中心的なデータ構造です。SKB はネットワークパケットを保持する、バッファーの連結リストです。このようなリストは送信キュー、受信キュー、SACK キュー、再送信キューなどとして機能することが可能です。SKB は、パケットデータをフラグメントとして保持することができます。Linux SKB は最大 17 個のフラグメントを保持することができます。

linux/include/linux/skbuff.h
define MAX_SKB_FRAGS (65536/PAGE_SIZE + 1)  => 17

各フラグメントは、x86 で最大 32KB のデータ (PowerPC では 64KB) を保持します。パケットを送信する場合、そのパケットは送信キューに置かれ、詳細は以下のような制御バッファー構造に保持されます。

    linux/include/linux/skbuff.h
struct tcp_skb_cb {
    __u32       seq;                    /* Starting sequence number */
    __u32       end_seq;    /* SEQ + FIN + SYN + datalen */
    __u32       tcp_tw_isn;
        struct {
                u16 tcp_gso_segs;
                u16 tcp_gso_size; 
        };
    __u8        tcp_flags;  /2* TCP header flags. (tcp[13])  */
    …
}

このうち tcp_gso_segs および tcp_gso_size フィールドを使用してセグメンテーションオフロードの情報をデバイスドライバーに通知します。

セグメンテーションオフロードが有効で、SACK メカニズムも有効である場合、パケットの損失と一部パケットの選択的な再送信により、SKB が tcp_gso_segs によってカウントされる複数のパケットを保持してしまう可能性があります。リストのこのような複数の SKB は、異なる SACK ブロックを効率的に処理するために 1 つにまとめられます。これには、リストの SKB 間でデータを移動します。さらに、データの移動中に SKB のフラグメントが最大数の 17 個に達する可能性があり、tcp_gso_segs パラメーターがオーバーフローして以下の BUG_ON() 呼び出しを引き起こし、該当のカーネルパニックの問題が発生する可能性があります。

static bool tcp_shifted_skb (struct sock *sk, …, unsigned int pcount, ...)
{
...
tcp_skb_pcount_add(prev, pcount);
BUG_ON(tcp_skb_pcount(skb) < pcount);   <= SACK panic
tcp_skb_pcount_add(skb, -pcount);
…
}

リモートユーザーは、TCP 接続の MSS (最大セグメントサイズ、Maximum Segment Size) を下限の 48 バイトに設定し、改ざんされた SACK パケットのシーケンスを送信することで、この問題を引き起こすことが可能です。MSS の値を最も小さくすると、セグメントごとに 8 バイトのデータのみとなるため、必要な TCP セグメントの数を増やしてすべてのデータを送信します。

謝辞

Jonathan Looney 氏 (Netflix Information Security)

その他の参考資料

RFC-2018 - TCP selective acknowledgments 
How SKB’s work

Netflix (レポーター) のオリジナルレポート

影響を受ける製品

Red Hat Product Security チームは、本件によるセキュリティー上の影響を重要な影響と評価しています。

以下の Red Hat 製品のバージョンが影響を受けます。
直接的な影響を受ける製品

• Red Hat Enterprise Linux 8
• Red Hat Enterprise Linux 7
• Red Hat Enterprise Linux 6
• Red Hat Enterprise Linux 5
• Red Hat Atomic Host
• Red Hat Enterprise MRG 2
• Red Hat OpenShift Container Platform 4 (RHEL CoreOS)
• Red Hat OpenShift Online
• Red Hat OpenShift Dedicated (および依存するサービス)
• OpenShift on Azure (ARO)
• Red Hat OpenStack Platform (イメージ同梱カーネル)
• Red Hat Virtualization (RHV-H)

二次的な影響を受ける製品 (基盤のプラットフォームを更新する必要があります)

• Red Hat Virtualization (RHV)
• Red Hat OpenStack Platform
• Red Hat OpenShift Container Platform 3

Red Hat の Linux コンテナーはカーネルの脆弱性の影響を直接受けませんが、そのセキュリティーはホストカーネル環境の整合性に依存しています。Red Hat では最新バージョンのコンテナーイメージを使用することを推奨します。Red Hat Container Catalog の一部である Container Health Index を使用すると、常に Red Hat コンテナーのセキュリティー状態を確認できます。使用中のコンテナーのプライバシーを保護するには、これらの攻撃に対して (Red Hat Enterprise Linux、CoreOS、Atomic Host といった) コンテナーホストを更新する必要があります。Red Hat はこのユースケース向けに更新された Atomic Host をリリースする予定です。

該当の CVE の影響を受ける Red Hat 製品

問題の詳細と背景情報

以下の 3 つの不具合が報告されています。不具合別の簡単な説明とその影響を以下に示します。

CVE-2019-11477

Linux カーネルは、16 ビット幅の TCP_SKB_CB(skb)->tcp_gso_segs での整数オーバーフローに対して脆弱です。リモートの攻撃者がこの問題を悪用すると、システムをクラッシュし、DoS (サービス拒否) 攻撃を実行することができます。

CVE-2019-11478

Linux カーネルは、攻撃者が TCP 再送信キューを断片化するよう改ざんされた SACK のシーケンスを送信できる不具合に対して脆弱です。攻撃者は断片化されたキューをさらに悪用し、同じ TCP 接続に対して受信された後続の SACK に対して連結リストを悪用できるようになります。 これにより、CPU が時間を過剰に費やして、リストの再構築を試みるため、サービス拒否 (DoS) が発生します。 

CVE-2019-11479    

Linux カーネルは、攻撃者が MSS の値が低い改ざんされたパケットを送信してリソースを過剰に消費させることができる不具合に対して脆弱です。攻撃者は、Linux カーネルを強制し、応答を複数の TCP セグメントに分割し、各セグメントに 8 バイトのデータのみが含まれるようにすることが可能です。これにより、同じデータ量を送信する必要のある帯域幅が大幅に広がります。さらに、追加のリソース (CPU および NIC の処理能力) を消費します。これには、攻撃者の継続的な攻撃が必要で、攻撃者がトラフィックの送信を停止した直後に影響は停止します。 この攻撃が継続される間、システムのパフォーマンスは低下するため、一部のユーザーでサービス拒否 (DoS) が発生します。

脆弱性の診断

以下の診断スクリプトを使用して、現在ご使用のシステムにこの不具合による脆弱性が存在するかどうかを判断します。正規のスクリプトであることを確認する場合は GPG 分離署名 もダウンロードします。