TCP SACK Panic: Linux カーネルパニック脆弱性の概説

This post is also available in: English (英語)

概要

Linux システムのカーネル脆弱性、CVE-2019-11477、CVE-2019-11478、CVE-2019-11479 が新たに見つかりました。これらの脆弱性は カーネル 2.6.29 (2009 年 3 月公開) とそれ以降にリリースされた新しい Linux オペレーティングシステムのすべてに影響し、TCP で接続を待ち受けるサービスを実行するシステムにカーネルパニックを引き起す可能性があります。これら脆弱性が悪用されると、リモートからの攻撃によりサーバーがサービス拒否 (DoS) 状態に陥る可能性があります。ただしリモートからコードを実行される心配はありません。これらの脆弱性の原因は TCP SACK (選択的確認応答) と最大セグメントサイズ (MSS) の実装にあります。リモートの攻撃者は、TCP 接続の MSS を下限である 48 バイトに設定し、改ざんした SACK パケット シーケンスを送信することにより、受信側のソケットバッファをオーバーフローさせることができます。ほとんどの Linux ディストリビューションでは、パッチをリリース済みです (RedHat/Ubuntu/openSUSE)。システムに直ちにパッチを適用することができない場合、攻撃をファイアウォールルールかトラフィック制御ポリシーで遮断することも可能です。この攻撃は非常に単純なため、利用可能な POC (Proof of Concept) 攻撃がすぐに出てくることでしょう。そうなれば数日以内に保護されていないシステムのエクスプロイトをもくろみ、大規模な DDoS 攻撃が仕掛けられることが予想されます。

TCP SACK

RedHat はこの攻撃に関する詳細説明を提供していますので、ここでは攻撃についての簡単なレビューを含めるにとどめます。TCP SACK 攻撃は、送信側 TCP SACK (選択的確認応答) のメカニズムと受信側の最大セグメントサイズ (MSS) 設定のバランスを崩すことによって可能となる攻撃です。SACK (選択的確認応答) は、どの TCP パケットが受信側に正常に受け入れられ、どのパケットは再送が必要かを送信側システムに通知するためのメカニズムです。MSS (最大セグメントサイズ) は受信側が設定する設定で、ネットワークでどれだけの大きさのパケットを受信できるかを指定します。ここで受信側の MSS が 48 バイトという最も低い設定に設定されている場合、送信側は要求を満たすためにより多くのセグメントを送信する必要があります。受信側が大規模なネットワーク転送 (たとえばメディアファイルそのほかのサイズの大きいファイルの転送) を要求すると、送信側は送信されたパケットが正常に受信されているかの監視を開始します。ここで受信側の MSS が低く設定されていると、送信側で格納可能な SACK キュー長に制限があるために不均衡が発生し、送信側の SACK キューがオーバーフローする可能性があります。こうして未送信パケットのオーバーフローが大きくなりすぎると、カーネルパニックの状態が引き起こされ、その結果、サービス拒否 (DoS) につながる可能性があります。

影響

Linux カーネル 2.6.29 以降および TCP サービスを実行するオープンなポートを持つすべてのサーバーがこの攻撃に対して脆弱です。本脆弱性による潜在的な影響を理解するため、Shodan でいくつかのクエリを実行した結果を図 1 に示します。本稿執筆時点では 194 万 4,975 台の Linux ベースサーバーがインターネット上で見つかります。うち 54 万 3,797 台のサーバーが 80/tcp で HTTP サービスを実行し、15 万 2,416 台のサーバーが 22/tcp で sshd サービスを実行し、12 万 6,143 台のサーバーが 443/tcp で HTTPS サービスを実行しています。これらサーバーに特別なファイアウォール ルールやトラフィック制御ポリシーが適用されていない場合、これらのサーバーはすべて潜在的に攻撃の標的となる可能性があります。

図 1 Shodan で見つけることができる公開済み Linux システム

対策・緩和策

この攻撃は Linux カーネルシステムを標的にしています。バージョン 2.6.29 以降のカーネルを実行している Linux システムがある場合は、システムを利用可能な最新 Linux リリースにアップグレードする必要があります。クライアントが Google Cloud Platform (GCP)、Microsoft Azure、そのほかの Infrastructure as a Service (IaaS) を使用している場合は、Linux のアップグレード手順に従ってすべての Linux システムを最新のリリースにアップグレードしてください。

Amazon は今回確認された SACK Panic 攻撃からの被害を受ける可能性のあるサービスとして、次のものを識別済みです。

• AWS Elastic Beanstalk
• Amazon Linux および Amazon Linux 2
• Amazon Elastic Compute Cloud (EC2)
• Elastic Load Balancing (ELB)
• Amazon WorkSpaces (Linux)
• Amazon Elastic Container Service for Kubernetes (Amazon EKS)
• Amazon ElastiCache
• Amazon EMR

上記の識別済み Amazon サービスの一部ないし全部を使用しているクライアントは、該当サービスを最新バージョンに更新する必要があります。以下は上記各 Amazon サービスに対して実行すべきアクションの簡略一覧です。

AWS Elastic Beanstalk

• クライアントが Amazon のマネージドプラットフォーム更新を使用している場合、これらのシステムは選択したメンテナンス期間中に更新されます。クライアントがマネージドプラットフォーム更新を有効にしていない場合は、こちらのマネージドプラットフォーム更新の手順を参照して有効に設定してください。

Amazon Linux および Amazon Linux 2

• 新しい Linux カーネルがアップロードされ Amazon Linux リポジトリから利用可能になっています。クライアントは各 EC2 インスタンスで次のコマンドを実行し、カーネルアップデートを受信する必要があります。
  sudo yum update kernel

Amazon Elastic Compute Cloud (EC2)

• 各 EC2 インスタンス内で次のコマンドを実行します。
  sudo yum update kernel

Elastic Load Balancing (ELB)

• お使いの ELB が Classic Load Balancer ないし Application Load Balancer の場合、または Network Load Balancer (NLB) で TLS ターミネーション (TLS 終端) を利用している場合は、ユーザー側でとくにアクションをとる必要はありません。
  お使いの Network Load Balancer で TLS ターミネーションを利用していない場合は、Linux ベースの EC2 インスタンスのカーネルにパッチを適用する必要があります。その方法については、こちらをご確認ください (2019-06-27 08:00 修正更新)。

Amazon WorkSpaces (Linux)

• 新しい Linux WorkSpaces はすべて自動的にアップデートされるためクライアントによるアップデートは不要です。

Amazon Elastic Container Service for Kubernetes (Amazon EKS)

• 現在実行中のすべての EKS クラスタはこの攻撃から保護されています。クライアントはすべてのワーカーノードを置き換え、最新の EKS バージョンを使用する必要があります。

Amazon ElastiCache

• ElastiCache VPC はデフォルトで信頼されていない TCP 接続を受け入れないため、影響を受けません。
• クライアントがデフォルトの ElastiCache VPC 設定から変更されている場合は、ElastiCache セキュリティグループが AWS のベストプラクティスに従っていることを確認し、信頼されていないクライアントからのトラフィックをブロックするように設定する必要があります。詳細は Amazon の Amazon VPC と ElastiCache のセキュリティを参照してください。
• クライアントに VPC 外で実行中の ElastiCache があり、ElastiCache をデフォルト設定から変更している場合は、ElastiCache セキュリティグループを使用してインスタンスを構成する必要があります。詳細は Amazon のセキュリティグループ: EC2-Classicを参照してください。

Amazon EMR

• Amazon EMR は、Linux を実行している EC2 インスタンスをクライアントの VPC 内で起動します。これらはデフォルトで信頼されていない TCP 接続を受け入れないため、影響を受けません。
• EMR VPC の設定を変更したクライアントがある場合は AWS のベストプラクティスに従っていることを確認し、信頼されていないクライアントからのトラフィックをブロックするように設定する必要があります。詳細は Amazon のセキュリティグループを使用してネットワークトラフィックを制御するを参照してください。
• AWS のベストプラクティスに従った EMR セキュリティグループを設定しないことを選択したクライアントについては、次のガイドラインに従うことができます。
  • 新しいクラスタ - EMR ブートストラップアクションを使用して Linux カーネルを更新し、各インスタンスを再起動します。詳細は Amazon の追加のソフトウェアをインストールするためのブートストラップアクションの作成を参照してください。
  • 既存のクラスタ - クラスタ内の各インスタンスで Linux カーネルを更新し、一度に 1 つずつインスタンスを再起動します。

結論

本脆弱性は、仕組みが単純で深刻度が高いため、数日以内に大規模な DDoS 攻撃が確認されることになっても不思議ではありません。Linux カーネルをできるだけ早くアップデートすることが重要です。また、パブリッククラウドで実行中のサーバーをインターネットに公開して TCP サービスをオープンにしている場合、直ちにパッチを適用するか、少なくともファイアウォール ルールを設定して攻撃をブロックすることが極めて重要です。管理者は本稿で提供した対策ガイドラインを活用してシステムを保護してください。

更新履歴

• 2019-06-27 08:00 Elastic Load Balancing (ELB) の修正手順についての誤りを修正しました。