未認証で届くOpenSSHのコードの約16%は、既定で無効な実験アルゴリズムの解析器だった — 脆弱性を1件も消さずに重大度を下げる手口

Anthropic の Frontier Red Team が10月20日に出した発表は、脆弱性を見つける話ではない。見つけずに重大度を下げるという話である^[1]。 オープンソース25プロジェクト・500万行超に Claude を走らせ、 「既定の構成で未認証の相手に届いてしまう不要なコード」を493件挙げた^[1]。 中心の実例は OpenSSH で、10.4 の sshd では未認証の相手が約4,500行のポスト量子署名(ML-DSA-44)の実験コードに到達でき、 これは既定の sshd において OpenSSH 自前の未認証到達コードの約16%にあたる^[1]。 既定では無効なアルゴリズムであり、管理者が明示的に除外していても、 解析だけは先に走っていた^[1]。 本紙がこれを取るのは、先に止められないOTに残る時間差で書いた宿題——修正が工程の都合で待たされ、まれには数十年という尺度になる^[2]——に対して、 初めて別方向の答えが数字付きで出たからである。 ただし発表側は、この手口で脆弱性が消えるわけではないとも書いている^[1]。

測ったのは「穴」ではなく「届く範囲」である#

前提を1つ置く。個別の脆弱性を見つけて直す進め方は規模の面で伸びない、というのが発表本文の出発点である。 critical な1件を直しても、残っている未知の脆弱性について何も分からない^[1]。 対してコードの到達可能性を削ると、いま悪用されている最中のものを含めて、 未知の脆弱性すべての重大度を同時に下げられる^[1]。 穴の数は変わらないが、穴までの距離が伸びるという考え方である。

具体的な操作として挙がっているのは、コードを適切な門の後ろに移すことである。 認証前から認証後へ、0クリックから1クリックへ、既定で有効から明示的な opt-in へ、 プロトコルの最初のメッセージからセッション状態機械の奥へ^[1]。 手法は3つに整理されている^[1]。

対象の25プロジェクトは、期待される到達範囲の違いで3群に分けられている。 誰でも到達できる前提の Public(10件)、認証済み利用者に供するGated(11件)、運用者自身の環境に閉じた Private(4件)である^[1]。 発表本文は、Public なら既定構成で相当の割合が到達可能でも当然であり、 Gated ではその逆が期待される、と前置きしている^[1]。 つまり同じ493件を群で割らずに読むと意味が変わる。

493件の内訳として公表されている数字#

散文に出ている数値をそのまま採る。群別の全内訳は本文中の図に置かれていて、 散文には Gated 群と構成相互作用の数字だけが書かれている^[1]。

Gated 群については、11件すべてに意図せず到達可能なコードがあった^[1]。 ただし同じ文に但し書きが付く。そのコードはどのプロジェクトでも全行数に対しては大きな割合ではなかった^[1]。 発表本文は、これらの指摘はどれも単独で即座に悪用できるものではなかったとも明記している^[1]。 増えていたのは必要以上の攻撃面であって、既知の攻撃経路ではない。

OpenSSH——既定で無効なアルゴリズムの解析器が、認証の前に動いていた#

削減幅が全行数比で最も大きかったのは、意外にも OpenSSH だったと発表本文は書いている^[1]。 10.4 の sshd で、未認証の相手が ML-DSA-44 のために追加された新しい実験コード 約4,500行に到達できた^[1]。 ML-DSA は既定で有効ではない。それでもコードには到達でき、 管理者がそのアルゴリズムを明示的に除外した場合でも同じだった^[1]。 sshd はクライアントが送ってきた鍵種別を先に解析し、 証明書なら埋め込まれた CA 署名の検証まで済ませてから、 その鍵種別が許可されているかを確認していた^[1]。 4,500行は、既定の sshd における OpenSSH 自前の認証前コードの約16%である^[1]。

ここから先の経緯が、この発表の中でいちばん地味で、いちばん情報量がある。 指摘とパッチは開発者に報告され、10.5 では確認が解析より前に移された^[1]。 そのうえで Claude は、自分たちが通した修正に2つの穴を見つけている^[1]。

利用者署名の経路は許可された公開鍵リストの後ろに正しく置かれていたが、CA 署名の経路はそうではなかった^[1]。 結果として、鍵交換を完了できる相手なら、バイナリ内のあらゆる公開鍵署名検証器に到達できた^[1]。 発表本文の締め方も淡々としている。OpenSSH は世界で最も監査されている C コードの一部である。 そこで不要な到達可能性が生き延びるなら、どこでも生き延びうる^[1]。

「拒否」が既定で開いていた——4つの無関係なプロジェクトで同じ形#

本紙の読者にとって、OpenSSH の行数よりも効くのはこちらだと考える。 Claude は、無関係な4プロジェクトで独立に同じ型の問題を見つけた^[1]。

管理者が遠隔クライアント向けのアクセス規則を、IPアドレスではなく ホスト名やワイルドカードのパターンで書く。接続が来ると、サーバはその規則を クライアントのホスト名と比べる。ところがサーバがホスト名を知るかどうかは、 逆引きDNSを制御する別のオプション次第で、多くのプロジェクトではそれが既定で無効だった^[1]。 逆引きが無効なら、サーバが持っているのはIPアドレスだけで、 規則はそのアドレスと文字列として比較される。ホスト名のパターンはIPアドレスに一致しない。 したがって拒否規則は一度も発火せず、リストは開いたまま(fail open)になる^[1]。 ホスト名規則がDNS逆引きの有効化に依存すると文書に書いているプロジェクトはあったが、 この書き方をした拒否リストが開いたまま倒れることを書いているものは1つも無かった^[1]。

同種の例がもう2つ挙がっている。1つは、クライアント証明書の提示を必須にする設定と、 その確認を必要時まで遅らせるつもりだったコードが衝突し、確認が完全に無効化されていた例である^[1]。 信頼済みクライアントのみを受け入れる設定のサーバが、誰からの接続でも受け入れていた^[1]。 既定の設定で両方のオプションが警告なしに受理され、文書には証明書要件が落ちることの記述が無く、 この組み合わせは21年間そのソフトウェアに存在していた^[1]。 もう1つは、TLS クライアント証明書を要求するオプションが、 設定が別の名前空間を通って読まれる一部のエンドポイントでは黙って無視されていた例である^[1]。 証明書なしのクライアントが TLS ハンドシェイクを完了してセッションを開けたが、無視されたことは何も記録されなかった^[1]。 設定名の短い形——多くの例文が使っている形——が、該当エンドポイントでは落ちていた^[1]。

発表側が自分で書いた限界#

この発表を「防御側が追いついた」と読むと、発表本文の記述と合わない。順に拾う。

検証の作りは逆に厳しい側に振れている。手法は3パスの Claude skill にまとめられ、 各パスは空のコンテキストから始まり、前のパスから短い引き継ぎだけを受け取る^[1]。 各パスでコードから入口の目録を作り、指摘は1件ずつ動的トレースで確認する^[1]。 既定構成の指摘については門を設計・実装し、プロジェクト自身のテストスイートと ブラックボックス回帰スイートをベースラインに対して走らせ、 改変ビルドが同一の結果になることを要求する^[1]。 発表側はこれを OSS-Scanner に統合する作業を進めているとしている^[1]。

フィジカルAIから見て、何が動いたのか#

本紙が止められないOTに残る時間差で残した宿題は、自分の装置が既知の穴を抱えて動き続ける日数を測れているか、だった。 発見量は増えても、稼働中の機械では安全に適用できる時まで修正が待たされ、 まれには数十年の尺度になると発表側自身が書いていたからである^[2]。 今回の手口は、その待ち時間を短くするものではない。待っている間の重大度を下げるものである^[1]。 止められない機械にとって、効く方向はこちらのほうが素直だと考える。

ただし誤読しやすい点を1つ潰しておく。これは「直さずに守る」ではない。 OpenSSH の事例で実際に行われたのは、確認の位置を変えるソースコードの変更であり、 10.6 として出荷されている^[1]。 装置を持っている側から見れば、やはり更新作業が1回必要である。 変わるのは、同じ1回の停止で守れる範囲だ。 個別の脆弱性を1件直す更新は、残りの未知について何も変えない^[1]。 到達範囲を削る更新は、未知のものを含めて重大度をまとめて下げる^[1]。 停止枠が年に数回しか取れない現場では、1回の停止枠に何を載せるかが選択であって、 その選択肢の性能が今回変わった、という読み方になる。

構成だけで済む部分もある。発表本文は末尾で、使われていない解析器・レガシープロトコル・ ダッシュボードを無効化することが、ほとんど費用をかけずにリスクを下げると書いている^[1]。 Claude は実行時ログと構成を突き合わせて、必要な機能だけが有効になっているかを 確認することもできるとされる^[1]。 出荷時の既定で有効なまま誰も使っていない機能、という形は、 産業用の装置やロボット制御系にも持ち込みやすい問いである。 ただし今回の測定対象にそれらは入っておらず、本紙も検証していない。

本紙が最も重く見るのは、行数ではなく fail open のほうである。 物理の側の作法はフェイルセーフ——異常時は安全側に倒す——であり、利用規約の更新が自律的に物理行動をとる装置に要求したのも、Claude が切断されたときに 装置が安全な状態を保持できることだった^[3]。 一方で今回見つかったのは、管理者が書いた拒否規則が、 逆引きDNSという別の既定値のせいで一度も発火しない構成である^[1]。 しかもその挙動を文書に書いているプロジェクトは1つも無かった^[1]。 安全要件としての「倒れる向き」は、ソフトウェアの既定値の組み合わせの中では 宣言されていなかったということになる。

この構図は、本紙がModel Hardware Standardの回で評価した配置——安全限界を学習された方策の内側ではなく、 装置の参照ファイルという外側の記述に置く——と同じ弱点を共有する。 外側の宣言は、それ自体が構成であり、別の構成と衝突しうる。 今回の162件のうち94件は、安全制御が黙って切れた組み合わせだった^[1]。 宣言した安全限界が有効であることを、誰がどの頻度で確認するのか。 ロボットを自律運用する側にとって、今回の発表が差し出した道具は 脆弱性の発見器ではなく、自分の装置の既定値が何を開けているかの目録を作る手続きだと 本紙は読む。Claude が25プロジェクトで最初にやったのも、 17,000件超の構成オプションの目録を作ることだった^[1]。