世界を動かす技術を、日本語で。

execve()を利用したローカル特権昇格

概要

  • FreeBSDのexecve(2)に ローカル権限昇格 の脆弱性
  • CVE-2026-7270 として登録
  • 全サポートバージョン が影響対象
  • ワークアラウンドなし、アップグレードが必須
  • 修正済みバージョンや 対応方法 を明記

FreeBSD-SA-26:13.exec:execve()経由のローカル権限昇格脆弱性

  • FreeBSD Projectによる セキュリティアドバイザリ (2026年4月29日発表)
  • 対象: 全サポートバージョンのFreeBSD
  • 脆弱性名: CVE-2026-7270
  • 報告者: Ryan(Calif.io)
  • 修正済みコミット: stable/15, releng/15.0, stable/14, releng/14.4, releng/14.3, stable/13, releng/13.5

背景

  • execve(2) は実行ファイルやスクリプトの起動に用いられるシステムコール
  • プログラムパス、引数、環境変数を指定して新しいイメージを起動

問題の内容

  • カーネルの演算子優先順位バグ によりバッファオーバーフローが発生
  • 攻撃者が制御するデータが 隣接するexecve(2)引数バッファを上書き する可能性

影響

  • 非特権ユーザー による root権限の取得 が可能となる危険性

ワークアラウンド

  • 回避策なし

解決方法

  • 脆弱なシステムを 修正済みのFreeBSD安定版またはリリース/セキュリティブランチ へアップグレードし、再起動

    • base system packages からインストールされた15.0-RELEASE(amd64/arm64):
      • pkg upgrade -r FreeBSD-base
      • shutdown -r +10min "Rebooting for a security update"
    • binary distribution sets からインストールされたRELEASE(amd64/arm64, FreeBSD 13のi386):
      • freebsd-update fetch
      • freebsd-update install
      • shutdown -r +10min "Rebooting for a security update"
    • ソースコードパッチ によるアップデート:
      • パッチダウンロードとPGP署名検証
        • fetch https://security.FreeBSD.org/patches/SA-26:13/exec.patch
        • fetch https://security.FreeBSD.org/patches/SA-26:13/exec.patch.asc
        • gpg --verify exec.patch.asc
      • パッチ適用・カーネル再構築・再起動
        • cd /usr/src
        • patch < /path/to/patch

修正詳細

  • 各ブランチの 修正コミットハッシュ を明記
    • stable/15/:c3e943e78e06
    • releng/15.0/:934b48683c4f
    • stable/14/:ae00a52921ca
    • releng/14.4/:943aa64ba91a
    • releng/14.3/:f04c40607b8f
    • stable/13/:d619e3a3c0ec
    • releng/13.5/:7c5c37ac8f8f
  • 修正内容の確認:git show --statコマンド
  • コミット数比較:git rev-list --count --first-parent HEAD

参考情報

  • 最新アドバイザリ: FreeBSD公式セキュリティ情報ページ

Hackerたちの意見

IV. 回避策 > 回避策はありません。あらまあ。

V. 解決策 > 脆弱性のあるシステムを、修正日以降の日付のサポートされているFreeBSDの安定版またはリリース/セキュリティブランチ(releng)にアップグレードして、システムを再起動してください。誰もがただfreebsd-updateして再起動できるわけじゃないから、そうだね、「あらまあ。」って反応がいいよね。

この脆弱性はSUIDバイナリに依存してないの?

なんで?ただアップデートすればいいのに。

HNの技術的理解度が低すぎる気がしてきた。こういうエクスプロイトを見たときに、読者は「ハッカーズ」みたいなカルトクラシック映画を頭に思い描いてるんじゃないかな。

IV. ワークアラウンド すべてが壊れていてひどいと認めつつ、なんとかユーモアを持って笑う方法を見つける。

これは4月28日のもので、15.0R-p7でパッチが当てられました。

-p8が15.0-RELEASEの現在のパッチレベルだから、もしみんながパッチをちゃんと当ててたら、もう2回再起動してるはずだよ。

自分たちの仕事を偶然見つけるのっていいね。楽しいウォークスルーが載ってるブログ記事もチェックしてみてね:https://blog.calif.io/p/cve-2026-7270-how-i-get-root-on-free... AIが生成した動作するエクスプロイト、解説とプロンプトもここにあるよ:https://github.com/califio/publications/tree/main/MADBugs/fr...

あなたのボットのブログは平均以上のレベルだね。ボットをここまで良くするために、たくさんの時間をかけたんだろうね。

「私たち」って言うのはちょっと無理があるよ。アルゴリズムに人格を与えてるだけじゃなくて、実際の作業は何もしてないからね。だから、「私が[人工知能のダウジングロッドのブランド]に指示したことがたまたま出てきて嬉しい」って言った方がいいんじゃない? これが所有権を主張するチャンスだよ。ボタンを押したのは自分だってはっきり言えるんだから。

Califはここ数ヶ月で本当にすごいことをやってるね。CalifはThai Duongの新しい会社だよ。

いつも優しくしてくれてありがとう :)

おお、これは結構大きいね。気づかなかったけど、もう更新してたわ。

memmove(args->begin_argv + extend, args->begin_argv + consume, args->endp - args->begin_argv + consume); // ← こういうバグのあるCコードがあるから、いいものが作れないんだよね。危険な関数呼び出しの引数で算術演算してるのに、明示的な境界チェックがないなんて。

「バグなんて書かないよ」って、そうだね。

  • args->endp - args->begin_argv + consume); + args->endp - (args->begin_argv + consume)); 正直、私が関わるプロジェクトでは数学演算子の優先順位を禁止して、混合演算子のコードには必ずカッコを使わせるか、複数の文に分けるようにしようかと思ったこともある。自分でもそうしてるし。これでたくさんのミスを見てきたし、無駄に時間をかけて解読したり確認したりしてる人も見てきたから、ほとんどのコードではその微々たる文字数の節約のためにやる価値がないと思う。
  • と + 演算子は同じ優先順位なんだよね。同じ演算子(両方とも -)だったら、似たようなバグも起こり得るし。だから、これを演算子の優先順位や混合演算子のせいにするのは正しいのか分からない。ただ、最終的には「consume」を引く必要があるってことだよね。

そのルールを一般化して、カッコを追加することで解釈が変わるような状況では必ずカッコを使うようにした方がいいと思う。整数の加算と乗算はそれに該当すると思うけど、他には特に思いつかないな。それ以外はカッコを必須にすべき。a - b - cは順序に依存するから、決定論的で分かっていてもね。面倒なバグを探してコードをスキャンしてる時に、期待通りに動いてるかを確認するために余計な時間をかけたくないんだ。そういうのが時間を奪って、もっと面白いコードの部分に集中できなくなるから。

スモールトークには数学演算子の優先順位がなくて、最初はすごくイライラしたけど、今はそれが良いアイデアだと思うようになった。

確か、いくつかの業界や政府のコーディングスタンダードでは、関数の引数で評価を行うことを許可していないんだ。コンパイラが変なことをする可能性があるし、人間のミスも考えられるからね。こういう基準をソフトウェア開発のルールに取り入れて、こういうセキュリティホールを避けるべきだと思う。

それはポニーもやってたね。演算子の優先順位のルールは難解すぎるし、手動メモリ管理が必要なのも面倒だよね。

一度、Cの知識を評価したいという面接を受けたことがあるんだけど、ポインタ演算の印刷物を見せられて「バグを見つけて」って言われたんだ。(実際には、/* は常にコメントの開始で、ポインタの参照による割り算ではないという古いパズルだったかもしれない。)俺は「まず、これはめちゃくちゃだね。ここ、ここ、ここ、ここにカッコを入れるよ」って言ったら、「バグは直したけど、どこにあったか教えてくれる?」って聞かれた。仮説を出したけど、「本当の答えは、演算子の優先順位を知る必要があるコードを書くべきじゃないってことだよ。そんな退屈な情報を頭に入れておくのは無理だ。」って言った。こんなうざいスマートアースに面接されるのは相当イライラしただろうけど、結局その仕事をもらえたし、その根本的な考えには賛成してるよ!

exeCVE()のCVE

CVEをexecveに入れてる。

誰がこんなことを思っただろうね。