.NETのLinux配布物に所有権の不備｜上書き更新で終わらない再導入の手順

Microsoftは2026年10月25日、Linux向け.NET配布物の所有権に関する脆弱性CVE-2026-114148を公表しました。対象のASP.NET Coreアーカイブから導入した環境では、修正版を同じ場所へ上書きするだけでは対処を完了できません。Webサービスの運用担当者は、配布物の種類と展開時の所有権を調べ、修正済みの配布物から新しい空のディレクトリへ再導入してください。

本稿は10月26日にMicrosoft公式GitHubの個別勧告と導入資料を確認したニュース・対応解説です。主題はBrotliとは別のローカル権限昇格です。バージョン番号だけでなく、どのアーカイブを誰の権限で展開し、実際にどのサービスが利用するかを対応付ける必要があります。以下の調査票や試験項目は本サイトの提案で、侵害を再現した実測ではありません。

低権限の利用者が実行ファイルを変更できる条件

今回の問題は、アーカイブ内の数値によるユーザー・グループ所有権が展開先へ保持され、意図しないローカルアカウントがファイルや書き込み可能なディレクトリを制御できる状況で生じます。そのファイルを、より高い権限で動くアプリが利用すると、改変を通じた権限昇格につながり得ます。勧告は特権での展開や、所有権を保持するコンテナのアーカイブ取り込みを例示しています。

CVSS v3.1の基本値は7.8で、公式の深刻度はHighです。ネットワーク越しに認証なしで直ちにコードを実行できるとする問題ではなく、ローカルで低い権限を持つ攻撃者が前提です。本稿で確認した一次資料から実環境の悪用を確定できないため、悪用中や被害発生を推定しません。

Web運用で重要なのは、サービス用アカウントと実行環境を管理するアカウントの境界です。仮想例として、アプリのプロセスが変更できる場所へ共有ランタイムを置き、別の高権限サービスもそれを使う構成を考えます。最初のプロセスの権限を得られた場合に、共有ファイルを経由して影響が広がる可能性を調べます。これは構成を点検する例であり、今回その侵入経路が観測されたという意味ではありません。

8・9系の公式配布とsource-buildを区別する

Microsoftが配布する8・9系では、対象はASP.NET CoreのLinux用runtime・targeting-packのtarballです。通常のruntimeに加えてcomposite版も含みます。対象範囲は8.0.0以上8.0.33未満、9.0.0以上9.0.22未満で、それぞれ8.0.33と9.0.22が修正版です。ほかのMicrosoft配布.NET RuntimeやSDKのtarballを、この問題の対象へ一律に含めないでください。

台帳では、aspnetcore-runtime、aspnetcore-runtime-composite、aspnetcore-targeting-packという配布物の種類を残します。Linuxのアーキテクチャやmusl向けなどのRIDも照合します。「.NET 8を利用」という情報だけでは、対象の配布物から導入したか、どの所有者になったかは分かりません。OSパッケージで管理している場合は、その提供元の勧告と導入履歴も確認します。

一方、source-buildのLinux配布物は、該当範囲で生成されるすべてのtarball種別が対象です。修正先は8系が8.0.133、9系が9.0.123、10.0.1xx系が10.0.114-servicing.26522.126、10.0.4xx系が10.0.403-servicing.26523.112、11プレビュー系が11.0.100-rc.3.26522.148です。これらは対応するsource-build SDKリリースを表す番号で、実行用runtimeの番号とは区別します。

10・11系について今回の所有権問題が対象とするのはsource-buildのtarballです。source-buildはビルド・エンジニアリング工程で使う入力であり、利用したという事実だけで、本番の共有ランタイムも同じアーカイブから導入されたとは言えません。ビルド入力、展開した作業領域、そこから作ったパッケージやイメージ、本番への配布先を順に追います。

NuGet更新やファイルの上書きで終えない

公式勧告は、NuGet参照を更新すること、新しいアーカイブをダウンロードすること、既存の導入先へ展開することだけでは既存環境を直せないと説明しています。パッケージ復元自体が、このtarballの所有権問題を持ち込むわけでもありません。依存ライブラリーの更新結果と、共有ランタイムの導入状態を別々に確認してください。

この違いは作業票の完了条件にも影響します。ダウンロード済み、ファイル配備済み、サービス切り替え済み、所有権確認済みを分けます。アプリのビルドが成功しても、運用サービスが古い導入先を参照していれば対応は終わりません。また、修正版の存在は、過去のファイルが改変されていないことの証明にはなりません。

新しい導入先を信頼できる管理経路で用意する

まず対象の導入ディレクトリと、それを利用するWebサービス、定期ジョブ、コンテナイメージを特定します。公式勧告に沿って切り替え前に対象アプリとサービスを停止し、信頼する発行元から、必要な系列・構成・アーキテクチャの修正済みアーカイブを取得します。チェックサムは信頼できるリリース情報と照合します。

MicrosoftのLinux手動導入資料は、配布サイトのチェックサムとsha512sumの結果を照合する手順を示しています。照合する値を、アーカイブと一緒に出所不明の場所から入手しても、信頼する発行元との一致を確認したことにはなりません。資料内の古い版を示すコマンド例を、そのまま今回の修正先としてコピーしないことにも注意します。

導入先は新しい空のディレクトリにします。共有・特権の導入では信頼できる管理者が制御し、親ディレクトリも未信頼アカウントから変更できない場所を使います。旧環境からバイナリー、プラグインなどをコピーして新環境へ混ぜず、併存が必要な版も信頼できる修正済み配布物から導入するのが公式の方針です。

アプリの設定を引き継ぐ必要があっても、実行ファイルのコピーと同じ作業として扱わないことを本サイトは勧めます。必要な設定の出所、変更履歴、秘密情報を確認し、構成管理から再生成できるものは再生成します。不審な変更がある場合は、取り除く前に調査担当と記録の保全を進めてください。

展開時はアーカイブの所有者を復元しない

公式勧告は、アーカイブのユーザー・グループ所有権を復元せずに展開するよう求めています。GNU tar向けの例では、umask 022、--no-same-owner、--no-same-permissionsを組み合わせます。次は勧告に基づく実行部分の例です。検証済みアーカイブと、新しい空の導入先を指定し、共有環境では信頼できる管理者のコンテキストで実施する前提です。

(
  umask 022
  tar -xzf "$PATCHED_ARCHIVE" -C "$NEW_DOTNET_ROOT" \
    --no-same-owner --no-same-permissions
)

この例だけで導入先の安全性が自動的に保証されるわけではありません。展開後のファイル・ディレクトリ・親ディレクトリが想定する所有者の管理下にあるかを確認します。グループの書き込みやACLを通じた変更可能性も点検します。所有者名だけを見て判断せず、数値IDとの対応を実際のホストやコンテナで照合するのが実務上の確認点です。

シェルの版とサービスが選ぶ版は一致するとは限らない

新しい導入先を用意したら、アプリとサービスの設定を変更し、再起動して利用先を確認します。dotnet --list-runtimesはインストール済みruntimeの一覧を調べる手段ですが、管理者が開いたシェルのPATHにあるdotnetを調べただけでは、全サービスの選択先を証明できません。起動コマンド、環境変数、検索パス、定期ジョブも対応付けます。

Microsoftのアプリ配布方式の解説は、framework-dependentが実行環境にあるruntimeを使い、self-containedはアプリ側にruntimeを含むことを区別しています。ホストの共有runtimeを変更した結果を、runtimeを同梱する成果物にも一括して適用済みと扱わないでください。どちらを配備しているかを先に把握することが、更新漏れを減らします。

本サイトの提案は、各サービスの旧導入先、新導入先、停止・起動時刻、稼働プロセス、確認担当を一行で結ぶ作業記録です。ヘルスチェックだけでなく、認証、DB接続、外部連携、バックグラウンド処理など通常の経路を試します。確認後は古い導入先が検索パスやジョブから選ばれないことを確かめ、組織の配備手順に沿って廃止します。

コンテナとビルド工程は作成元から直す

コンテナでは、動いている個体のファイルだけを直しても、後の再作成で古い状態へ戻る可能性があります。公式勧告は、信頼できる入力と所有権を制御した展開でカスタムイメージを再ビルドし、置き換えたコンテナを配備するよう説明しています。イメージ内の展開処理と、実行時のマウントで上書きされる場所を分けて確認します。

source-buildの工程も、修正済み入力へ切り替えたうえで、古い展開済み作業領域を使い回さず、新しい信頼できる場所へ展開し直します。そこから作ったruntime・SDKパッケージや独自イメージに所有権が引き継がれていないか調べ、必要な成果物を再構築します。工程内のアーカイブを、本番へ導入済みの共有runtimeと同一視しないことが重要です。

CIでは、キャッシュや保存したビルド領域が再利用される地点を棚卸しする方法を提案します。新しい入力を一度取得できたことだけで合格にせず、再試行、別ランナー、次回ジョブでどの展開先を使うかまで見ます。既存の非root実行と読み取り専用コンテナの解説も、実行ユーザーと書き込み先の確認に使えますが、今回の配布物の修正を置き換えるものではありません。

通常動作と書き換えできないことを両方確認する

最終確認では、修正済みの配布物を使うことと、未信頼アカウントが実行環境を変更できないことを別項目にします。検証環境で、想定するアプリユーザーから新導入先を変更できないか、必要なデータ領域だけが書き込み可能かを確認してください。テストのために本番のruntimeへ不審なファイルを配置する必要はありません。

業務が止まった場合も、原因を調べず旧環境へ戻すのを既定にしないでください。必要な併存版、依存OSライブラリー、設定の参照先、所有権の違いを切り分けます。段階切り替えと復旧計画は必要ですが、脆弱な導入先を再公開する場合のリスクと、到達範囲を制限する一時対応も担当者が判断できるようにします。

同日の.NET定例外更新の公式発表にはBrotliなど別の修正も含まれます。今回の所有権点検だけで、そのすべての影響確認を完了したとは扱いません。本稿の完了条件は、対象配布物と所有権の調査、信頼できる新導入先への再構築、稼働先の切り替え、将来の再作成元の修正までを確認することです。版番号の更新成功だけで閉じないようにしてください。