BootHole バグによるサーバーへのリスク – 知っておくべきこと

今月も新たな BWAIN が登場しました。BWAIN は、Bug With An Impressive Name (印象的な名前のバグ) という意味であり、特別な名前を付けることで注目を集めて、ユーザーに注意を喚起し、何らかの行動を起こすことを期待するものです

今回の脆弱性は共通脆弱性識別子 CVE-2020-10713 が採番されていますが、それだけでなく印象的な名前と、陽気なロゴが与えられました (過去には、テーマソングまで作られた脆弱性もあります)。

その脆弱性は BootHole と呼ばれ、ロゴにはブーツに開いた穴から幼虫が頭を突き出す様子が描かれています。

BootHole の悪しき点は、コンピュータのブートプロセスそのものの整合性に影響を与えるという点です。言い換えると、この脆弱性によりデバイスの電源を入れてからオペレーティングシステムが起動するまでの間の無防備な時間に実行可能なコードを埋め込まれる危険性があります。

幸いなことに、この脆弱性は大多数の人々にとっては無関係なものです。この脆弱性は GRUB (Grand Unified Boot Loader) として知られるブートローダに存在するものですが、Windows や Mac のデバイスで利用されていることはほとんどありません。

ただし、システム管理者にとっては問題です。GRUB (正式名称は GRUB2 ですが、単に GRUB と呼ばれることがほとんど) は、いくつかの人気な Lunux ディストリビューションにおいてデフォルトのブートローダとして利用されています。

言い換えれば、自分のサーバールームにある物理的なサーバーであれ、クラウドサービス上の仮想サーバーであれ、もし Linux のサーバーを所有しているのであれば、少なくとも理論上は、大事なコンピュータが危険な状態に置かれている可能性があります。

ちなみに、記事の先頭にある脆弱性のロゴには幼虫 (ワーム) が描かれていますが、これは今回の脆弱性がワームによる攻撃の危険性があることを示唆するためかもしれません。

つまり、この脆弱性を用いて被害者のサーバーのうち一つにマルウェアを感染させた攻撃者は、自動的に同じサーバーラック内にあるほかのサーバーや、さらには離れた場所にあるサーバーにまでマルウェアの感染を広げることができる可能性があるということです。

起動前の攻撃を排除するためのサーバーセットアップが可能であるため、このような事態が起きることは不可能とまでは言いたくありませんが、可能性は低いと考えられます。

一般的に、この脆弱性を悪用するには攻撃者はスーパーユーザー (root ユーザー) の権限をあらかじめ取得する必要があります。

初めからルートユーザーとしてログインする必要があるのであれば、許可されていないリモートコード実行 (RCE) の脆弱性は存在しません。Linux を提供する Red Hat 社がこのバグの影響を「高」や「重大」ではなく、「中程度」と評価したのはこのためと考えられます。とはいえ、この脆弱性はコンピュータのブートプロセスに影響を与え、オペレーティングシステムそのものを操作するマルウェアを埋め込まれるリスクがあります。

ブートプロセスについて

PC が登場した初期の頃は、ブートプロセスはほとんど完全に無防備でした。

コンピュータの電源が入ると、CPU は ROM (リードオンリーメモリ) から BIOS (ベーシックインプット /アウトプットシステム) と呼ばれる小さなプログラムを実行します (ROM のファームウェアは、PC を解体しマザーボード上のチップを交換することでしか変更できないため、ここまでは安全なプロセスです)。

T次に、BIOS はハードディスクの最初の物理セクタから 512 バイトを無作為に読み取り、RAM (0x07C00 から 0x07DFF までを扱うメモリ) に読み込むことで、ブートローダとして動作します。

その 512 バイトのセクターの最後の 2 バイトがブートシグネチャとして知られる 0x55AA (2 進数では 01010101 10101010) の場合、正当なブートローダーであると見なされ、BIOS は 0x07C00 番地 (16ビットのセグメント表記では 0000:7C00) に直接移動し、起動プロセスが開始されます。

マスターブートローダコードは、ブート可能なパーティションを見つけ、そこからセカンダリブートセクターを読み込んで独自の基本的な認証を行い、制御を順番に引き渡すことになっています。その後、セカンダリブートセクターが OS カーネルを見つけてロードし、プロセスが続行されます。

このプロセスは、「靴のつまみ皮 (ブートストラップ) で自分自身を持ち上げる」という発想から、ブートストラップ法として今日まで知られています。これは現実の世界では物理的に不可能ですが、英語では自分自身の努力で高い地位に昇っていくことのたとえとして使われています。

いうまでもなく、かつてのブートセクターは書き込みが可能で、しばしば何かしらの情報が入っていました。

誤ってセクターゼロに書き込むことによって引き起こされる破損は、PC が起動できなくなる典型的な例ですが、ストーンド、アンジェリーナミケランジェロなどの悪名高いブートセクターウイルスの感染が起きると、数年に及ぶトラブルが発生します。

特に、ブートセクターはオペレーティングシステムより先に実行されるため (実際、オペレーティングシステムのロード自体、ブートセクターに依存しています)、ブートセクターの実行中はオペレーティングシステムによる保護が適用されません。

メモリ保護、特権プロセスの概念、ユーザーおよびスーパーユーザー (root ユーザーまたは管理者アカウントとも呼ばれる) の概念、ファイルまたはディレクトリのアクセス制御リストなど、何も存在しないのです。

そのためサイバー犯罪者はしばしば、ブートセクターからオペレーティングシステムを操作して、ほかのマルウェアを偽装したり、隠蔽したりするために作られたルートキットやマルウェアプログラムなどを隠す場所としてブートセクターを利用してきました。

セキュリティを増強するために

ブートプロセスを保護するため、ノートパソコンであれ、サーバーであれ、NUC であれ、最新のコンピュータのほとんどはセキュアブートと呼ばれる機能を搭載しており、多くの場合デフォルトで有効になっています。

BIOS は、UEFI と呼ばれるシステムに置き換えられています。これは、ユニファイドエクステンシブルファームウェアインタフェースの略で、BIOS のプロセスのように盲目的ではありません (実際には、BIOS はまだ存在します。ほとんどのコンピュータでレガシーモードとも呼ばれる BIOS モードに戻すことができますが、通常、切り替えを行うにはコンピュータを手元に用意する必要があります)。

セキュアブートモードでは、デバイスの出荷前にマザーボードに保存される暗号化キーに基づいて、ブートストラッププロセスのさまざまなステージがデジタル署名を使用して検証されます (ほとんどのコンピューターでは、これらのキーを個人用のキーに置き換えることで署名プロセスを管理できますが、そのためにはやはりデバイスへの物理的なアクセスが必要です)。

GRUB で起動する場合、プロセスでは通常、以下のようなローディングとデジタル署名の確認が行われます。

  • UEFI ファームウェアを確認。
  • ファームウェアを使用し、メインブートローダをロード。
  • メインブートローダを確認。これは、Linux のシステム上では、Microsoft によって署名された shimまたは PreLoader と呼ばれる中間ブートローダであり、コンピューターのハードウェアはこれらの署名キーをすでに信頼していると思われます。
  • shimPreLoader ブートローダを使用し GRUB ブートローダをロード。これは通常、Linux ディストリビューションの作成者によって署名されています。
  • GRUB ブートローダを確認。
  • テキストベースの設定ファイルを読み込み、ブートローダメニューを表示。

デジタル署名により、サイバー犯罪者がブートローダプログラムを置き換えることは困難になり、ブートセクターウイルスやルートキットの侵入を防止することができます。サイバー犯罪者にとってオペレーティングシステムの起動前に実行されるレベルの低いコードを挿入することは困難であるため、そういったコードの埋め込みを根本的に阻止することが可能と思われます。

これにより考えられることが何か、分かったでしょうか。

テキストファイルの危険性

上記のテキストベースの設定ファイルは、デジタル署名をされていません。あるいは少なくとも、GRUB 自体によって確認は行われておらず、ほとんどの Linux ディストリビューションでは、オペレーティングシステムが読み込まれる前にファイルを認証する追加のプロセスは存在しないようです。

そして、BootHole の脆弱性は、設定ファイルの読み取り中にバッファオーバーフローを発生させる GRUBブートローダーのパースエラーです。

ここに大きな問題があります。

テキストファイルは純粋なデータであるはずですが、GRUB ブートローダに長すぎる行を読み取らせると、ブートローダコードをクラッシュさせるだけでなく、そこから制御を奪うことができるようです。そのため、テキストファイルからコードをそのまま読み取らせて、データ内でコード実行を続けることができます

この脆弱性を発見した Eclypsium 社は、これを「エラーのコメディ」とでも呼べるようなバグだと述べています。

GRUB は、読み込む行がバッファーに対して長すぎることを正しく検出し、エラーをキャッチすると、そのエラーを忠実に通知します。ユーザーが、もしその瞬間に画面を見ていたならばそれに気づくかもしれません。

しかし、GRUB はエラーを通知はしても、それを無視して実行し続けるのです。

簡単に言うと、ルートユーザーの権限があり、GRUB.CFG ファイルにテキストを書き込むことができる者であれば、誰でもテキストファイルを介してブートローダコード (シェルコードという専門用語で呼ばれる) にこっそり侵入することができます。

しかし、テキストファイルはコメディ SF の『銀河ヒッチハイク・ガイド』シリーズの言葉を借りると「ほとんど無害」と見なされているため、セキュアブートストラッププロセスに含まれるほかのファイルのようにデジタル署名を用いた制限を受けません。

言い換えると、コンピュータを再起動し、オペレーティングシステムが起動する前に実行される任意のブートローダコードを、サイバー犯罪者はデジタル署名を気にすることなく埋め込むことができます。

残念ながら、ブートローダコード内のこのようなバッファオーバーフローは、常に攻撃者に悪用される危険性があります。これは、UEFI が比較的シンプルな環境であるため、最新のオペレーティングシステムが提供するような予防メカニズムの多くが存在しないためです。

ブートストラッププロセス中は、データ実行防止 (オーバーフローしたバッファー内のデータの実行を停止する機能) や、アドレス空間配置のランダム化 (安定してプログラムのクラッシュを引き起こすことができる場合でも、制御を乗っ取ることが難しくなる機能) などの保護機能が存在しません。

もしあなたがプログラマーならば、ブートローダの世界は 1984 年と同じような状況です。

対策

どうやら、Eclypsium 社の脆弱性レポートは、ブートローダにおいてバッファオーバーフローの重大性が高いことを考慮して、GRUB のバグ修正に留まらずほかにも同様のコーディングエラーがないかコードレビューを行うことを促しているようです。

これを受けて、GRUB の対策チームは今回のバグ (CVE-2020-10713) だけでなく、さらにCVE-2020-14308、CVE-2020-14309、CVE-2020-14310、CVE-2020-14311、CVE-2020-15705、CVE-2020-15706 および CVE-2020-15707 と採番された 7 個のバグについても修正を実施しました。

このことも念頭に置き、以下の対策の実施を検討してください。

  • 使用している Linux ディストリビューションについて、GRUB のアップデートがないか確認してください。 GRUB が持つサイズと複雑さが必要でなければ、ほかのブートローダに切り替えることも検討してください。
  • 不正な変更が加えられていないか、GRUB.CFG ファイルを監視することを検討してください。 このような監視ツールがまだない場合は、inotifywait コマンドを確認してください。ただし、GRUB の設定ファイルを上書きできるルートユーザーの権限を持っているサイバー犯罪者は、いずれにせよ監視を無効にするか迂回できる可能性があるので、留意してください。
  • サーバーへのルートレベルのアクセス権を持つユーザーを見直しましょう。 これはサイバー犯罪だけでなく事故を防ぐためにも、定期的に実施する必要があります。
  • 可能であれば常に二要素認証を使用してください。これにより、個別のシステム管理者の責任が明確になり、保護の強化に役立ちます。また、単純なフィッシングやキーロギングといった手口を使ってサイバー犯罪者がパスワードを盗むことを阻止できます。

セキュアブートを使用していない場合、ブートローダコードはデジタル署名の認証によって保護されないことにご注意ください。ただし、おそらくサイバー犯罪者は初歩的な技術を用いてブートローダファイルとディスクセクターに直接書き込むより、GRUB.CFG ファイルを介してブートローダに変更を加えるほうが容易であるため、これら対策はすべて検討に値します。

Linux パーティションを一切持たない Windows または Mac デバイスで、GRUB を使用するコンピュータはほとんど存在しないと思われます。しかし、仮にあなたがこのバグによる直接の影響を受けていないとしても…

これらの対策については誰にとっても有益なものですから、ぜひ検討してみてください!

結論

ある評論家が指摘しているように (下記の @Gabriel のコメントを参照)、ノートパソコンまたはサーバーに物理的にアクセスできる攻撃者は、外部デバイスからの起動が有効になっている場合、デジタル署名されていないブートローダコードを実行するために、「感染予備軍」の Linux USB ドライブ (ブービートラップが仕組まれた GRUB セットアップが施されているもの) を使用することができます。これはたとえば、Windows のコンピュータ上でも可能です。

これは、物理的にコンピュータを操作できる攻撃者がコンピュータ起動時にセットアップスクリーンにアクセスすることができるのであれば、関係ありません。なぜなら、そのような場合攻撃者はまず間違いなくセキュアブートを一時的に無効にし、この脆弱性を利用する必要はないからです。

しかし、IT 部門の社員だけがシステム設定の変更を行うことができるようセットアップ画面へのアクセスは無効になっている代わりに、たとえば緊急時にリモートユーザーがトラブルシューティングを手伝うことができるように USB からの起動が可能になっているような職場用コンピュータの場合、BootHole バグがセキュアブートの迂回の手口として実際に使用される可能性があります。

つまり、物理的にアクセスできる攻撃者は、デバイスを開いてハードディスクを抽出したり、他の侵入的または時間のかかる手法を使用したりせずに、セキュアブートがオフになっている場合と同じようにコンピューターにアクセスできる可能性があります。

これについては、二つの対策が考えられます。

  • 外部デバイスからの起動を無効にしましょう。 多くの IT 部門では、ビジネス用ノートパソコンの一般的なセキュリティ対策として、すでにこれを実施しています。こうすることで、コンピュータのセットアップ画面を安全にロックダウンすることができます。ただし、メーカーが提供するセットアップ画面のパスワード保護が強度な場合、ロック解除コードを忘れてしまった時にベンダーですらそれをバイパスすることができません (Lenovo のビジネス用ノートパソコンなどがその一例です。セットアップパスワードを忘れた場合、マザーボードの交換が必要になります。これはセキュリティ機能であり、バグではありません)。
  • Linux を利用していなくても、コンピューターのオペレーティングシステムとファームウェアのアップデートは常に確認してください。 セキュアブートは、不正またはバグのある使用済みブートローダへの署名に使われたキーの使用を防ぐため、ブートローダー署名キーについて既知の許可リストと不許可リストの両方を使用しています。しかし、これらの更新が追加されるには時間がかかることがよくあります。バグがなく更新が必要ないものであっても、廃止されたキーで署名されたブートローダは、いずれもまず再署名の上再発行する必要があるからです。