なぜネットワークビジネスは Meltdown/Spectre を無視しているのでしょうか?

The Register がMeltdown/Spectre 投機的実行の脆弱性に関するニュースを報じてから 7 週間が経ち、業界のほぼすべての部門がパッチの適用、再パッチの適用、そして世界を Spectre から守る方法の検討に奔走しています。

イーサネット スイッチ ベンダーは、ごく少数の例外を除いて、バグについての声明すら出していません。

スイッチには脆弱なアーキテクチャが存在することが分かっています。LAN やデータ センターでパケットを転送する ARM コアが非常に多く存在します。

一体何が起こっているのでしょうか？なぜイーサネット市場は、テクノロジー業界が経験した最も辛い危機の一つを、まどろみながら乗り越えているのでしょうか？

イーサネットの仕組みに詳しい方なら、もう答えはお分かりでしょう。しかし、El Regの受信箱は、テクノロジー業界の誰もがネットワークに携わっているわけではないことを改めて認識させてくれます。そこで、イーサネットに興味のある方のために、MeltdownとSpectreがスイッチの最も深く暗い秘密を暴露しない理由をお伝えします。

この記事の議論と情報提供をしてくださった、オーストラリアのハードウェア デザイナーであり、Redfish Systems の CEO である Justin Clacherty 氏に感謝します。

まず、ネットワーク業界の巨人であるシスコに2つの質問をしました。「メルトダウン/スペクターはスイッチのデータプレーンから悪用される可能性があるのか​​？」そして、「これらの脆弱性はイーサネットスイッチのコントロールプレーンから悪用される可能性があるのか​​？」

どちらの場合も、予想通りの回答（「いいえ」）が得られ、シスコは脆弱性についてすでに開示した内容を参照しました（Switchzilla はこれらの脆弱性の影響度を「中程度」と評価しています）。

Cisco の議論は、当然のことながら、Cisco 製品に関するものですが、主要なイーサネット ベンダーのサイトで Meltdown/Spectre に関する記述を検索してもほとんど見つからない理由を理解する価値はあります。

シスコの見解では、メルトダウン/スペクター攻撃は、ほとんどのネットワークハードウェアにとってアーキテクチャ上起こりにくいものです。同社はThe Registerへのメールで次のように述べています。「これらの脆弱性を悪用するには、攻撃者は影響を受けるデバイス上で細工されたコードを実行できなければなりません。…これらの脆弱性を悪用する手段は存在しません。」

そして、このような記述がほぼすべてのイーサネット スイッチに当てはまるのには理由があります。

データプレーン攻撃

イーサネット スイッチがパケット プロセッサとして脆弱なアーキテクチャ (ARM など) を使用していたとしても、リモートの攻撃者はイーサネット フレームにデータを挿入して脆弱性をトリガーすることはできません。

なぜダメなのでしょうか? ルーターの外部からは、スイッチに送信される内容を制御できないからです。

攻撃者がターゲット ネットワークと通信する場合、IP スタックを使用してパケットをルーターに送信します。つまり、OSI モデルの第 3 層 (ネットワーク層) に対応するインターネット層 (IP スタック モデル) を使用していることになります。

ルータは、IP パケットのデータ フィールドの内容を取得し、それを (適切な断片化を使用して) イーサネット フレームにフォーマットし、回線上に配置します。

データプレーン攻撃が実行可能だとしたら、攻撃を実行するにはLANへのアクセスが必要になります。それでも、内部の悪意ある侵入者は、イーサネットスイッチポートに対して何ができるでしょうか？以下はイーサネットフレームの図です。

フレームのほぼ大半は何らかのシグナリング情報です。スイッチはそれをチェックします。ペイロードには関心がありません。

また、シグナリング フィールドのほとんどは短いため、数バイトだけを必要とする攻撃を作成する必要があることにも注意してください。

例えば、偽装されたMACアドレスに基づいて、6オクテット（48バイト）の攻撃を何らかの方法で作成できるとします。では、4c:8d:79:d8:37:5cをMeltdown/Spectreをトリガーする文字列に置き換えるとどうなるでしょうか？

パケットプロセッサのカーネルメモリにアクセスできるというのは、一見難しそうに聞こえますが、パケットプロセッサは数百台のVMをホストする大規模サーバーとは異なります。パケットプロセッサが保存するデータのほとんどはMACアドレスであるため、異なるポート間の関連付けを高速かつ大規模に記憶し、パケットをスイッチングすることができます。

イーサネットスイッチへの攻撃が成功すれば、ネットワークがクラ​​ッシュする可能性が最も高くなります。これは望ましくありません。しかし、データセンター内にいる場合は、投機的実行の設計上の欠陥をいじることなく、いずれにせよネットワークをクラッシュさせることが可能です。

コントロールプレーン

では、スイッチのコントロールプレーンはどうでしょうか？ネットワーク全体を見渡す目として機能する、フル機能のコンピューターでしょうか？

これらのコントローラは脆弱なアーキテクチャを使用している可能性がありますが、それは脆弱性が悪用可能である、またはエクスプロイトが使用可能であることを意味するものではありません。

まず、Meltdown と Spectre は権限昇格のバグです。イーサネット スイッチ上の管理プロセスは (多くの場合、またはほとんどの場合) root として実行されており、スイッチ上の実行スペースを他のユーザー権限のプロセスと共有していません。

Cisco社はまた、スイッチはカスタムコードを実行しないロックダウンされたデバイスであることを強調しました。つまり、たとえコントロールプレーンが脆弱なアーキテクチャ上にあっても、攻撃者は管理ポートにトラフィックをドロップするだけでコードを実行することはできません。攻撃を実行するには、例えばCiscoの公式コード署名を偽装してスイッチに攻撃コードをフラッシュするなど、はるかに多くの労力が必要になります。

ログイン権限があれば、スイッチの管理ポートと通信でき、すでにネットワークを制御できるので、わざわざそうする必要はありません。

白い箱

これまではプロプライエタリ環境について議論してきましたが、急成長を遂げている「ホワイトボックス」スイッチ市場はどうでしょうか。ホワイトボックスとは、ユーザーがマシンにインストールしたオペレーティングシステムによって制御されるパケットプロセッサを搭載したスイッチのことです。

データ プレーンについて上で書いたことは依然として当てはまりますが、スイッチ上のカスタム Linux ビルドが脆弱になる可能性は確かにあります。

攻撃シナリオは依然としてひどいものです。インターネットから管理ポートへのパスはおそらく存在せず、管理ポートにアクセスできるのであれば、もっと有効な手段があります。®