酒呑ガジェット

〜静かな環境であなたに...こちらは音のでないコンテンツです。〜

【朗報】Linux、全裸のソースコードで銀行を守れていた 「隠さないから守れる」という30年の逆説

誰でも読めるコードなのに、銀行のサーバーを守れる理由

Linuxのソースコードは、誰でも読める形で公開されている。ログインプログラムも、暗号通信も、カーネルの中心部も例外ではない。攻撃者同様に読めてしまうコードで、なぜ銀行も企業もサーバーを預けられるのか。この一見矛盾した問いに対する、オープンソース三十余年の答えは「隠さないことで守る」という意外な構造になっている。

サーバー室の通路に浮かぶ盾のマークが、守られるLinuxサーバーを示すイメージ

「秘密」に頼らない設計思想——ケルクホフスの原理

公開と安全を両立させる第一の柱は、守るべきものの仕分けにある。ログインプログラムの場合、公開されているのは「入力された情報を確かめる手順」までで、利用者のパスワードや秘密鍵までは公開されない。秘密鍵は本人確認と暗号化に使う最重要データとして別枠で保護される。暗号の設計思想として古くから知られるケルクホフスの原理——「アルゴリズムが知られても、鍵の秘密だけで守れるべきだ」——をそのまま実装に落とし込んだ形だ。手順を知っても、本人だと証明する情報は別途必要になる。この分離が安全の土台だが、土台であって無条件の保証ではない。鍵の管理を誤れば漏れるし、実装を間違えれば壊れる。

では「全部秘密にすれば安全では」という問いには、二つの穴がある。一つは、非公開でも実行ファイルは解析できることだ。動作を観察し、機械向け命令を読み取る逆解析により、ソースが読めなくても構造は推測できる。もう一つは、公開には「外部の専門家が大勢点検できる」という逆方向の利点があること。多くの目が問題を見つけやすくするという考えはリーナスの法則として知られる。ただし「誰でも見られる状態」と「専門家が実際に時間をかけて点検する」のは別物で、特殊な条件や複雑な境界処理まで自然に網羅されるわけではない。

公開が生んだ教訓——Heartbleedと9年生きた穴

公開が生かされるとは限らない例も、歴史は記録している。暗号通信部品OpenSSLで2014年に公表されたHeartbleedは、相手が送った長さを適切に確かめず、余計なメモリの内容を返してしまう欠陥だった。影響する版の公開から修正まで約2年を要し、秘密が漏れる危険につながった。暗号の計算自体が強くても、その横の長さチェック一つで守り全体が破られる。カーネルの権限昇格弱点には2007年から2016年まで約9年生きたものがあり、有名なモリスワームの系譜をたどる弱点にも約25年の履歴がある。公開を活かすには、対象に合う専門知識と継続的な点検が不可欠だという教訓だ。

弱点に届くまで、何重もの壁

仮に弱点を発見されても、被害に至るには「その弱点に届く条件」が必要になる。Linuxは普段のアプリが動く領域とカーネルが動く領域を分け、アプリが中核処理を使う時はシステムコールという決められた入り口しか通れない。プログラムに何でもできる権限を渡さず必要な範囲に絞る最小権限の考え方を基に、呼び出しを制限するseccomp、操作を許可制にするSELinux、カーネルのメモリ配置を毎回変えて攻撃者に場所を当てさせにくくするKASLRなどが重ねられている。入り口を減らし、操作できる範囲を狭める——多層防御とは、壁があるから放置していいという意味ではなく、設定を確かめつつ元の穴も直し続ける前提の仕組みだ。

「提案できる」と「書き換えられる」は別

ソースを自由に改造できることと、公式のコードを書き換える権限は別物だ。Linuxカーネルでは、変更内容と理由を提案し、担当分野の開発者が検査・議論し、メンテナーの管理する領域から上流へ統合される。知らない人が直接本流を書き換えることはできない。もっとも、審査する人も間違える。2021年にはミネソタ大学の研究が、不正な変更提案と審査の信頼性を問題視した。この件は「送られた罠を全部その場で見破った」と単純化して語られがちだが、後の公式報告は5つの変更を個別に調べており、不採用のものも、不採用にしたものが実は有効な修正だったものもあり、経緯は一つではない。過去の変更の再点検も行われ、審査が絶対ではないことを組織自身が確認している。

XZ事件——0.5秒の違和感が止めたバックドア

その体制の限界を突きつけたのが、2024年に発覚したXZ Utilsのバックドア事件だ。XZはカーネルそのものではなく周辺で使われる圧縮部品で、「Jia Tan」を名乗るアカウントが数年かけて貢献を重ね、管理に関わる立場まで昇っていた。負担に追われる既存メンテナーの協力者への権限移譲すなわち配布物を扱う権限が渡されたのだ。外部の人間が勝手に公式を書き換えたのではなく、管理する立場の内部から仕込まれた。仕掛けは公開リポジトリのテスト用ファイルに隠した内容と、配布用アーカイブにだけ入った処理の組み合わせで動く二重構造で、要件が揃うと遠隔ログインが読み込むライブラリ経由で不正な影響を与える。署名がついていても、作った本人が不正を混ぜていれば無害さは保証されない。

この異常を検知したのは、データベース開発者のアンドレス・フロン氏だった。本人の報告では、開発版で遠隔ログイン時のCPU消費の異常に気づいたことがきっかけで、測定例では処理が約0.5秒長くなっていた。待ち時間の増加で片付けず、どの部品が処理を遅らせているかを追い、公開コードと配布アーカイブの違いを突き合わせた。2024年3月29日に問題が公表され、各ディストリビューションは影響確認と差し戻しを実施。当時公開済みの多くの配布版に問題の版は入っていなかったが、被害が世界中で皆無だと断言できる根拠もない。この件で決定的だったのは、公開そのものではなく、調べた人が公開を活かしたことだ。

公開の代償と、点検の自動化

公開には代償もある。修正前のコードとの差分を見れば、どこに問題があったか推測できてしまう。修正公開から利用者の機器へ更新が届くまでの時間差はパッチギャップと呼ばれ、更新前の古い状態の機器を狙う攻撃につながる。2019年のAndroid関連で報告されたbinder由来の弱点悪用は、以前の修正が届いていない機器が狙われた例だ(攻撃者が公開修正を読んだ経緯までは確定していない)。守る側は発見と修正を共有して対応を広げるほか、不規則な入力を繰り返すファジングで壊れ方を探す。カーネルではsyzkallerやsyzbotといった自動検査が使われ、メモリの不正アクセス検出機構と組み合わせて再現条件を開発者に伝える。

さらに2024年、GoogleはAIによる脆弱性発見「Big Sleep」を公表した。データ保存・検索ソフトSQLiteの、正式公開前のコードが対象だ。変更を手がかりに関連する処理を調べ、範囲外アクセスの問題を発見。既存の自動検査が見逃していた場所を、AIが別の調べ方で見つけ、開発者が当日中に修正した。公開前だったため、利用者に影響する前に対処できた。2025年のDARPAの競技大会でも、AIを使うシステムによる弱点の発見と修正が実証されている。ただし、いずれも「Linux全体の点検が終わった」「全ての弱点が消えた」証明ではない。AIは攻撃する側にも使える。公開だけで勝敗は決まらない。

読んだコードと、届いたファイルは同じか

もう一つの切り札が再現可能ビルドだ。同じソースから作り直した完成品が、配布された実行ファイルと1ビット単位で一致するかを比べる。同じソースだけでは足りず、使う道具の版や設定、作る手順も揃え、結果に混ざる時刻や保存場所の違いを除く。別の人が作っても一致すれば、「読んだコード」と「配られたファイル」が対応している検証の手がかりになる。XZ事件が教えた「リポジトリだけ確かめても配布物との違いを見落とす」リスクへの、構造的な回答だ。ただし元のソースに悪意があればそれも忠実に再現される。一致の確認と、内容の監査は別々に必要になる。

ネットの反応

Linuxは古典的なOSで、Unixという祖先の歴史を歩いている。故に今も脆弱性は明らかになり、パッチを当てる作業が続いている。コミッターは数万人に及んでおり、それだけのプロの目に常に光が当たっているから迅速にパッチアップが行われる。だが、それでも常に脆弱性に怯えている

Windowsのソースコードは今でもブラックボックス。これはPC利用者にとって安全なのかね

ケルクホフスの原理を知らないエンジニアが多すぎる

0.5秒のCPU遅延からバックドアを特定したの、もはや芸術。自分が運用者だったら「重くなっただけ」で流してた

AIの所感

このテーマの核心は、「公開するか秘密にするか」という二択が、実は誤った問いだった点にある。秘密にしていても実行ファイルは解析されるし、公開していても誰も読まなければ穴は残る。安全を決めてきたのは、コードの公開状態そのものではなく、公開されたものを誰がどこまで点検し、修正をどこまで速く配布できたかという運用の総量だった。HeartbleedもXZバックドアも、公開という仕組みの失敗ではなく、点検の人手と配布工程の監視が不足した場所の失敗として読める。

特にXZ事件が突きつけたのは、オープンソースの理想を支えてきた「善意のボランティア」構造の脆さだ。数年かけて信頼を積み上げるという人間の社会性そのものが攻撃面になった。だからこそ、再現可能ビルドや一人では出荷を決めない体制、AIによる事前検査といった「人を疑うための道具」の整備が、思想ではなく実務として進んでいる。公開は攻撃者にも防御者にも等しく開かれている——この非対称性を防御側に傾けるのは、結局のところ点検に割ける時間と人手であり、それはOSの性能表には現れない。次に大きな事件が起きたとき、0.5秒の違和感を追える人がどこかにいるかどうか。それが、公開された世界を守る最後の砦になっている。

-パソコン