UbuntuとDebianに深刻な脆弱性、パッケージの署名検証を回避しroot権限でコード実行の恐れ

Canonicalは2026年11月4日、UbuntuなどのLinuxディストリビューションでソフトウェアの取得・インストールに使われるAPTの脆弱性「CVE-2026-109518」に対する修正を公開した。Debianにも修正版が提供されている。この脆弱性を悪用すると、HTTP通信に介入できる攻撃者や悪意あるパッケージ配布ミラーが、ダウンロード時のリダイレクトと再試行処理を利用して、検証を通過していないパッケージをインストールさせる可能性がある。攻撃が成功すれば、root権限で任意のコードを実行されるおそれがある。

脆弱性を発見したのは、セキュリティ研究者のMax Justiczだ。Canonicalのセキュリティ情報によると、深刻度は「High（高）」で、CVSS 4.0の基本スコアは7.7と評価されている。ただし、HTTP経由でパッケージを取得するだけで攻撃が成立するわけではない。通信の改変に加え、リダイレクトとダウンロードの再試行が発生し、その後に対象の.debパッケージがインストールされる必要がある。

問題の原因は、APTがダウンロードしたファイルを扱う際に、ハードリンクを適切に処理していなかったことだ。これにより、通常は電子署名とハッシュ値によって保護されるパッケージの検証を回避される可能性がある。HTTPSへの切り替えは通信経路上の攻撃を防ぐ有効な対策だが、脆弱性そのものを解消するにはAPTの更新が必要となる。Canonicalは、安全に修正版を導入するため、更新時にダウンロードの再試行を一時的に無効化する方法も案内している。

image

Ubuntu+1

ハードリンクの再利用がパッケージの検証回避につながる仕組み

APTは通常、複数の検証を組み合わせることで、ダウンロードしたパッケージが改ざんされていないことを確認している。Ubuntuの公式文書によると、電子署名されたInReleaseファイルにはPackagesファイルのハッシュ値が記録され、Packagesファイルには個々の.debパッケージのハッシュ値が含まれる。この検証の連鎖によって、配布途中でパッケージの内容が変更されても検出できる仕組みだ。そのため、HTTPでパッケージを配布する場合でも、APTが取得したファイルを無条件に信用しているわけではない。

今回の脆弱性は、この暗号学的な検証方式ではなく、取得したファイルを開いて書き込む処理に存在していた。原因となったのは、複数のファイル名から同じファイルの実体を参照できる「ハードリンク」の不適切な再利用だ。ハードリンクで結ばれたファイルは同じデータを共有しているため、一方のファイル名を使って内容を書き換えると、もう一方から参照される内容も変わってしまう。

APT開発者のJulian Andres Klodeによる説明では、HTTPのリダイレクトと、一時的なサーバーエラーによるダウンロードの再試行を組み合わせることで、攻撃者が既存のハードリンクを介してファイルの内容を書き換えられる場合があったという。この問題を悪用すると、APTがファイルを検証した後に、その内容を攻撃者が用意したデータへ置き換え、未検証の.debパッケージをインストールさせることが可能になる。つまり、電子署名の秘密鍵やハッシュ関数が破られたのではなく、検証したファイルと実際にインストールされるファイルの整合性を保てない点が問題だった。

修正内容は、APTのソースコードに加えられた変更から確認できる。HTTPで取得したファイルの書き込み先を開く際にFileFd::Exclusiveを追加し、既存のハードリンクを通じた意図しない書き換えを防ぐよう変更された。また、ダウンロードを再開する場合には、既存のファイルを読み取り専用で開いたうえで元のリンクを解除し、新しい書き込み先を作成する。そこへ取得済みのデータをコピーし、ハッシュ値の計算に備えてファイルの先頭へ戻す処理が加えられている。

この修正の目的は、APTが書き込み先として開いたファイルを通じて、別のファイルの内容まで変更される事態を防ぐことだ。パッケージの電子署名やハッシュ検証の方式を変更するのではなく、検証対象のファイルがハードリンクを介して不正に書き換えられないようにしている。これにより、今回の脆弱性を悪用した未検証パッケージのインストールを防ぐ。

image

GitLab

攻撃の成立にはHTTP通信と再試行が必要

影響を受ける環境を判断するには、APTが使用している通信方式とダウンロードの再試行設定を確認する必要がある。今回の攻撃には、HTTP通信を改変できることに加え、APTがリダイレクトとダウンロードの再試行を行うという条件がある。再試行回数はAcquire::Retriesで指定され、値が0の場合はダウンロードの再試行が行われないため、この脆弱性を悪用できない。

Canonicalによると、Debian 12「bookworm」とUbuntu 22.04 LTS「Jammy Jellyfish」以降では、Acquire::Retriesの既定値が3に設定されている。APT開発者の説明では、この既定値はAPT 2.3.2から導入されたものだ。そのため、Ubuntu 22.04 LTS以降は標準設定でも攻撃の成立条件の一つを満たす一方、それ以前のリリースでは通常、再試行が無効になっている。

ただし、古いリリースであれば必ず安全というわけではない。管理者が設定ファイルや更新スクリプトでAcquire::Retriesを0以外に変更していれば、旧版でも影響を受ける可能性がある。反対に、再試行が有効でも、HTTP通信への介入や悪意あるミラー、実際のパッケージのインストールといった条件がそろわなければ、攻撃は成立しない。

また、脆弱性はAPTライブラリのHTTPバックエンドに存在するため、コマンドラインとGUIの違いによって影響範囲が変わるわけではない。apt、apt-get、aptitudeに加え、APTを内部で利用するUbuntuのグラフィカルなソフトウェア更新ツールも対象となる。一方、SnapはAPTとは別のパッケージ管理機構を使用しているため、今回の脆弱性の影響を受けない。

image

Ubuntu

Ubuntu向けの修正版は、Canonicalが11月4日に公開したセキュリティ告知「USN-8996-1」にまとめられている。対象にはUbuntu 26.10から14.04 LTSまでが含まれ、各リリースに対応するAPTの修正版が用意された。ただし、古いLTSではUbuntu Proや追加のサポート契約が必要になるため、修正版の有無だけでなく、実際に更新を受け取れる状態かどうかも確認しなければならない。

Debianについても、公式セキュリティトラッカーで修正状況が公開されている。Debian 12「bookworm」ではAPT 2.6.2、Debian 13「trixie」では3.0.4が修正版に当たる。開発版の「forky」と不安定版の「sid」についても、3.3.6で修正されている。

image

セキュリティトラッカー

これらのバージョンは、それぞれのリリースで脆弱性の修正を含むAPTのバージョンを示している。UbuntuとDebianではバージョン番号の付け方や修正のバックポート状況が異なるため、単純に番号の大小を比較するのではなく、利用中のリリースに対応する修正版と照合する必要がある。Canonicalは、APTのソースパッケージから導入された各パッケージのバージョンを確認するため、次のコマンドを案内している。

apt list --installed '?source-package(^apt$)'

Ubuntuでは、16.04 LTS以降のリリースでunattended-upgradesによるセキュリティ更新の自動適用が既定で有効になっている。Canonicalによると、この機能が有効であれば、修正版の公開から24時間以内に更新が適用される。ただし、自動更新機能が存在することと、実際に修正版が導入されていることは別だ。更新の失敗や設定変更の可能性もあるため、導入済みパッケージのバージョンを確認することが重要になる。

修正版を安全に導入するための手順

今回の脆弱性への対応で注意したいのは、修正対象がパッケージの取得とインストールを担うAPT自身であることだ。脆弱性が残った状態でAPTを更新するため、修正版の導入過程でも攻撃が成立する可能性を考慮する必要がある。Canonicalの公式解説では、HTTPSによる通信の保護と、ダウンロードの再試行を一時的に無効化する方法を緩和策として案内している。

それぞれの対策には役割の違いがある。HTTPSは通信経路上での改ざんを防ぎ、Acquire::Retries=0は今回の攻撃に必要な再試行を止める。一方、脆弱性そのものを修正するのはAPTの更新だ。修正コミットとCanonicalの説明を基に整理すると、次のようになる。

HTTPSを使用すれば、通信経路に介入する攻撃者がダウンロード内容を改ざんすることを防げる。しかし、パッケージの配布元であるミラー自体が悪意を持っている場合、HTTPSだけでは今回の問題を防げない。そのためCanonicalは、修正版を導入する際にAcquire::Retriesを一時的に0へ設定することを推奨している。この方法なら、通信経路上の攻撃者だけでなく、悪意あるミラーによる攻撃に対しても、今回の脆弱性に必要な再試行を無効化できる。

Canonicalがシステム全体の更新に推奨しているコマンドは、次のとおりだ。

sudo apt update && sudo apt upgrade -o Acquire::Retries=0

最初のapt updateでパッケージ一覧を更新し、続くapt upgradeでインストール済みのパッケージを更新する。-o Acquire::Retries=0は後半のapt upgradeに適用され、ダウンロードに失敗しても再試行しないよう指定するものだ。この設定はコマンドの実行時だけ有効となり、APTの設定ファイルを恒久的に変更するものではない。

システム全体の更新が難しい場合は、APT関連のパッケージだけを先に更新する方法も用意されている。Canonicalが示したコマンドは以下のとおりだ。

sudo apt update && sudo apt install -o Acquire::Retries=0 --only-upgrade '?source-package(^apt$)'

このコマンドでは、APTのソースパッケージから生成されたインストール済みパッケージを対象に、更新を実行する。--only-upgradeを指定しているため、対象となる新規パッケージを追加するのではなく、既存のパッケージを更新する処理となる。いずれの方法でも、更新後はAPT関連パッケージのバージョンを確認し、利用中のリリースに対応する修正版が導入されているか確かめる必要がある。

通信経路上での改ざんを防ぐためにHTTPSへ切り替える場合は、APTの取得先設定も確認する。Ubuntuでは/etc/apt/sources.listと、/etc/apt/sources.list.d/ディレクトリ内の.sourcesおよび.listファイルにリポジトリの情報が記録されている。これらの設定にあるhttp://のURLを、対応するhttps://へ変更することでTLSによる通信の保護を有効にできる。ただし、一部のコミュニティミラーはHTTPSに対応していないため、変更後にapt updateを実行し、正常にパッケージ一覧を取得できるか確認する必要がある。

HTTPSへの切り替えは、今回の脆弱性に対する有効な緩和策だが、APTの更新に代わるものではない。また、再試行を無効にする方法も、あくまで修正版を安全に導入するための一時的な対策である。最終的には、利用中のUbuntuまたはDebianに対応した修正版を導入し、APT関連パッケージのバージョンまで確認することが重要だ。

今回の問題は、パッケージの電子署名やハッシュ検証が正しく設計されていても、その前後のファイル処理に欠陥があれば、安全性が損なわれることを示している。APTを利用する幅広いツールが影響を受けるだけに、サーバーとデスクトップの双方で更新状況を確認する必要がある。特にHTTP経由のリポジトリを使用し、ダウンロードの再試行が有効になっている環境では、修正版の適用を優先すべきだ。