2024年8月9日

NECサイバーセキュリティ戦略統括部　セキュリティ技術センターの岩川、S田（ハンドルネーム）、田中です。

XZ Utilsに対してバックドアが仕掛けられたとして、2024年3月の報告[1]から大きな話題となり様々なところで取り上げられました。本記事では、今回仕掛けられたバックドアから、今後同様のバックドアが仕掛けれられた場合にどのように検知するかに焦点を当てて考察をします。

目次

XZ Utilsのバックドアの概要

XZ Utilsでは、xzそしてlzmaフォーマットをサポートするデータ圧縮ライブラリliblzmaとコマンドラインツールを提供します[2]。
2024年3月29日に、不正に変更された liblzma ライブラリが生成されliblzmaライブラリをリンクするソフトウェアが影響を受けるとしてCVE-2024-3094[3]が発行されました。
XZ Utils 5.6.0（2024-02-24）そして5.6.1（2024-03-09） release tarballに、不正な共同メンテナーによって仕掛けられたバックドアが含まれることが、通知されています[4]。
本バックドアを悪用することで攻撃者が sshd 認証を突破してリモートからのシステムに不正アクセスを可能にする可能性があります[5]。

バックドアの挙動と検知について

本節ではバックドアの検知においてポイントとなるXZ Utilsのバックドアの挙動と検知方法について考察をしていきます。

ビルドプロセス

ビルドプロセスにおいて、build-to-host.m4ファイルとbad-3-corrupt_lzma2.xzに仕掛けられた不正なコードを起点とし最終的にバックドアを持つオブジェクトファイルが生成されliblzma ライブラリにリンクされることでバックドアが混入します。バックドアを混入させるフローは他の記事ですでに詳しく解説がされています[6]。本節では検知するためにポイントとなる挙動をピックアップします。

ビルドする際には、まずconfigureスクリプトを実行します。configureを実行すると、処理の中でbuild-to-host.m4が実行され、テストファイルであるbad-3-corrupt_lzma2.xzから不正なスクリプトが抽出されます。

バックドアが仕掛けられた場合（xz-utils_5.6.1.orig.tar.xz）とバックドアが仕掛けられていない場合（xz-utils_5.6.1+really5.4.5.orig.tar.xz）のビルドにおいて、テストファイルへのアクセスについて監視して比較を実施しました。snapshot.debian.org[7]からバックドアが仕掛けられたソースコードは手に入ります。テストファイルへのアクセスは、inotify[8]を使い監視を実施しました。

バックドアが仕掛けられた場合（xz-utils_5.6.1.orig.tar.xz）はconfigureスクリプトを実行した際にテストファイルへのアクセスが複数見られますが、バックドアが仕掛けられていない場合（xz-utils_5.6.1+really5.4.5.orig.tar.xz）はアクセスが発生していません。このことから、ビルドプロセスにおいてどのファイルにアクセスするかはバックドアを検知する一つのチェック項目となると考えることができます。ビルドにおいて必要のないファイルにアクセスする場合は不審な点として検知ができます。検知とは異なる観点となりますが、ビルドに必要ないファイルは除いた環境でビルドを実施することで今回のようなバックドアの混入は防げたと考えられます。

sshdの応答時間

バックドアが仕掛けられたことにより、sshの応答時間が遅くなります。報告者はマイクロベンチマークを実施していた際に、sshdプロセスのCPUリソースの消費量から異常に気付きバックドアの発見に至ったと述べています[9]。

簡易的にバックドアが仕掛けられたライブラリと仕掛けられていないライブラリで比較を実施しました。snapshot.debian.org[7]からバックドアが仕掛けられたライブラリが含まれるパッケージは手に入ります。

検証はkali-linux-2024.2の仮想マシン[10]上で実施しました。以下のようにliblzma5_5.6.1-1_amd64.deb（バックドア有）とliblzma-dev_5.6.1+really5.4.5-1_amd64.deb（バックドア無）をそれぞれインストールして、インストール後にhyperfine[11]を使いsshの実行時間の1000回の平均値を計測しました。

不要なサービスを停止するなどしていないため厳密な比較・計測ではありませんが、バックドアを仕掛けられた場合は319.8ms、仕掛けられていない場合は137.5msとなり約180ms遅くなることが確認出来ました。
このことから応答時間・実行時間の変化はバックドアを検知する一つのチェック項目となると考えることができます。正規の修正による実行時間の変化はありますが、マイナーアップデートで大きな修正はしていないはずなのに実行時間が大きく変化した場合は注意をする必要があります。

valgrindのエラー

バックドアが仕掛けられたことにより、解析ツールvalgrind[12]においてエラーが出力されるようになります。XZ Utils 5.6.0のliblzmaライブラリの_get_cpuid関数においてエラーが発生します。_get_cpuid関数はバックドアのエントリに該当します。XZ Utils 5.6.1では攻撃者により、攻撃コードを更新されてエラーが発生しないように修正されています[13]。

snapshot.debian.org[7]からliblzma5_5.6.0-0.1_amd64.debとliblzma5_5.6.1-1_amd64.debを入手してそれぞれインストールして、インストール後にvalgrindをsshdに対して実行してみました。

5.6.0においてはエラーが発生して、5.6.1ではエラーが発生しないことが確認できました。
valgrindでエラーが発生しないかはバックドアを検知するための一つのチェック項目となると考えることができます。5.6.1では修正されましたが5.6.0ではエラー発生していたため異常を検知するためのひとつのきっかけになると考えられます。

GOTエントリの上書き

Linuxサーバーはsshdプロセスを稼働させ、SSHコネクションを受け付けます。XZ Utilsバックドアが混入したsshdプログラムでは、共有ライブラリであるlibcrypto.soに含まれる正規の関数の呼び出しを置き換え、不正な関数を呼び出すことで、攻撃者は認証を回避し、任意のコマンド実行が可能となります。具体的には、下記3つの関数の呼び出しを置き換えています[14]。本節では、このうちRSA_public_decrypt関数について取り上げます。

以降の説明では、バイナリにシンボル情報がなく関数名が定義されていないものに関しては、説明の便宜上、独自に関数名を定義して説明をしているのでご注意ください。

正規のRSA_public_decrypt関数は共有ライブラリであるlibcrypto.soに含まれる関数で、sshdはlibcrypto.soを動的にリンクしています。今回のバックドアにおいて実装された不正な処理は共有ライブラリliblzma.soに含まれており、sshdはliblzma.soとも動的にリンクしています。

ライブラリ関数の呼び出しをハイジャックするには、GOT（Global Offsets Table）のエントリを書き換えるGOT Overwriteという手法が有力です。ライブラリ関数の呼び出しに際して参照されるGOTのエントリに存在する正常なアドレス値を不正なアドレス値に書き換えることで、不正に関数を呼び出すことができます。

しかしながら、多くの場合にLinuxの実行ファイル（ELFファイル）はRelocation Read-Only（RELRO）機構[15]によりGOT Overwrite攻撃から守られています。RELRO機構にはいくつかの保護レベルが存在し、最も強力なFull RELRO環境下の場合、GOT領域はプログラム実行時に書き込みが不可となるため、一般にはGOT Overwrite攻撃の実現は困難になります。

checksec[16]によりRELRO機構のどの保護レベルが有効となっているかを確認できます。

XZ Utilsバックドアは、GNU indirect function（ifunc）機構[17]とRun-time Dynamic Linker Audit（rtld-audit）機構[18]を活用することにより、Full RELRO環境下のプログラムバイナリに対してもGOT Overwrite攻撃を実現したと考えられます。

GNU indirect function（ifunc）機構[17]は、同一の関数に複数の実装を用意しておき、実際に使用する実装をプログラムのロード時に決定する機能です。これにより、例えばCPUアーキテクチャの違いなど、環境ごとにバイナリを作成する必要がなくなります。使用する実装を決定する処理はresolverと呼ばれ、プログラムのロード時に実行されます。

Run-time Dynamic Linker Audit（rtld-audit）[18]は、GNU dynamic linker（ld-linux.so）が提供する機構です。この機構を利用することで、実行中のプロセスに対し、共有ライブラリのロードやシンボル解決などの動的リンクに関するイベントを監視および操作できます。

Full RELRO環境下の実行ファイルに対してもGOT Overwrite攻撃を実現するため、今回のバックドアは上述の2つの機構を活用し、sshdのGOT領域がread-onlyになる前にRSA_public_decrypt関数のGOTエントリを上書きし、不正なevil_RSA_public_decrypt関数を指すようにしています。

この攻撃手法を説明する前に、実行ファイルにifuncが存在する場合、そしてFull RELRO環境における動的リンカ（ld-linux.so）による処理の順序について簡単に説明します。下図は処理の概要図となります。

処理の概要は次の通りです。

Full RELRO環境下では、プログラム実行時にGOT領域をread-onlyに設定する必要があるため、動的リンカは遅延バインドではなく、プログラムのロード時に即時バインド処理を実施します。また、共有ライブラリにifunc 属性を持つ関数が含まれている場合は、動的リンカはどの実装を使うのかをバインド処理前に決定しておく必要があるため、はじめにifunc resolverを実行します。
resolverの処理が完了し、ifunc属性を持つ関数に対して実際に使用する実装が決定すると、動的リンカは共有ライブラリの関数シンボルとアドレスのバインド処理を行ない、GOTエントリを埋め、最終的にGOT領域をread-onlyに設定します。

そして今回のバックドアは、全体として下記のような手順でGOT Overwrite攻撃を実現しています。

上記手順の詳細な処理内容を以下で説明します。

(1)ifunc resolverの実行
今回のバックドアが含まれるliblzma.soには、lzma_crc32関数とlzma_crc64関数がifunc属性を持ち、resolverを利用しています。

(2)ifunc resolverからevil_cpuid関数の不正な呼び出し
XZ Utilsバックドアはその処理においてさまざまな難読化、ステルス化を施しています。その1つとして、ifunc resolverの中で、本来の__get_cpuid関数呼び出しが不正な_get_cpuid関数呼び出しに置き換えられています。この不正な_get_cpuid関数はliblzma_la-crc64-fast.oに含まれており、このオブジェクトファイルはビルド時にliblzma.soに静的にリンクされます。
ここで注意すべきは、ifunc resolverの実行時点ではGOT領域がまだread-onlyになっていない点です。_get_cpuid関数からの一連の処理において、cpuid関数呼び出しの直前に一時的にcpuid関数のGOTエントリを上書きし、cpuid関数の代わりにevil_cpuid関数を不正に呼び出します。下記は、liblzma.soのGOT領域で、cpuid関数のエントリが書き換えられていることを計測したものになります。

(3)rtld-auditのフック関数la_symbind64にrtld_hook_main関数を登録
evil_cpuid関数からの一連の処理において、動的リンカld-linux.soに含まれるrtld-audit機能の1つであるla_symbind64にrtld_hook_main関数を設定します。これにより、動的リンカが共有ライブラリ関数のシンボルのバインド処理を実施する度に、監査処理であるrtld_hook_main関数が呼び出されることになります。

下図はここまでの処理の動作概要図となります。

(4)動的リンカによるシンボルの即時バインド
先に説明した通り、Full RELRO環境下では、実行時にGOT領域をread-onlyに設定する必要があるため、動的リンカはifuncの解決が終わるとシンボルの即時バインド処理を実施します。そしてこのバインド処理において、rtld-audit機能の1つであるla_symbind64に設定されているrtld_hook_main関数が呼ばれることになります。

(5)rtld_hook_main関数はRSA_public_decryptのGOTエントリを上書きする
rtld_hook_main関数は、動的リンカによりRSA_public_decrypt関数のシンボルがバインドされた場合に、sshdのGOT領域にあるRSA_public_decrypt関数のエントリを不正なevil_RSA_public_decrypt関数のアドレスに上書きします。
動的リンカによりすべてのシンボルのバインド処理が完了したのち、sshdのGOT領域はread-onlyに設定されます。以後、sshdによるRSA_public_decrypt関数の呼び出しは、実際にはevil_RSA_public_decrypt関数が呼び出されることになります。

下図は(4),(5)の処理を加えた全体の動作概要図となります。

なお、ifunc resolverからの一連の処理において、sshdのGOTエントリを書き換えたとしても、その後の動的リンカによるシンボルの即時バインド処理により、正規のRSA_public_decrypt関数のアドレスに上書きされてしまいます。つまり、GOTエントリの書き換えは、動的リンカによるシンボルの即時バインド処理が完了した直後からGOT領域がread-onlyに設定される前までに実施する必要があるため、XZ Utilsバックドアはrtld-audit機能を利用したと推測されます[19]。

Full RELRO環境下でのGOT Overwrite攻撃は、今回のバックドアで実装された手法のように処理が複雑な一方で、実現できる手法は限られます。Full RELRO機構はプログラム実行時に実行ファイルのGOT領域をread-onlyにするため、攻撃者はGOT領域がread-onlyに設定される前に標的のGOTエントリを書き換えておく必要があります。したがって、実行時にGOTエントリが不正な値を指していないかを確認することが有効な検知の方法となります。
実際にデバッガを用いて、バックドアが混入していないsshdと、バックドアが混入しているsshdに対して、RSA_public_decrypt関数を示すはずのGOTエントリがどのような値になっているのかを確認してみます。

上記から、GOTエントリはバックドアが仕掛けられていない場合はRSA_public_decrypt関数を指しますが、バックドアが仕掛けられている場合はRSA_public_decrypt関数を指していないことが確認できました。このことからGOTに格納されているアドレスが正規の関数を指しているかを確認することはバックドアを検知する一つのチェック項目になると考えることができます。

まとめ

本ブログで紹介したXZ Utilsの挙動と検知するためのチェック項目をまとめると以下になります。

XZ Utilsのバックドアは、検知を回避するために非常に複雑で高度な方法を使用していました。このような攻撃は今後も発生する可能性があるため今回得られた知見をセキュリティ検査や開発時のCI/CDでのチェック項目に含めることでバックドアの検知に活かしていくことが重要と考えます。

参考文献

執筆者の他の記事を読む

執筆者の他の記事を読む

執筆者の他の記事を読む