世界を動かす技術を、日本語で。
このテキストは セキュリティ確認 のためのメッセージ。 ユーザーが ボットでないこと を確認するプロセス。 接続の 安全性確保 が目的。 待機指示 とプロセス進行中の案内。 自動処理や認証手順を示唆。
毎回のアップデートで新しいサプライチェーン攻撃か、Mythosからの修正を引くくじ引きみたいなもんだよね。
それか、セキュリティに対してYOLOアプローチを取らないFreeBSDみたいなOSに切り替えるのもアリだよ。セキュリティの修正は、FreeBSDカーネルに無計画に放り込まれることはなくて、FreeBSDのセキュリティチームを通過して、パッチがsrcツリーに入った数分後にはバイナリ更新（FreeBSD Updateやpkgbase経由で15.0-RELEASE用）も出されるから。だいたい、"パッチをプッシュしました"ってメッセージがSlackに流れるのに数秒、パッチのアップロードに10〜30秒、ミラーの同期に最大1分かかる感じ。
それに、あのテストや動画にDebianが出てこないのも面白いよね。
セキュリティの理由でBSDに切り替えるなら、なんでFreeBSDなの？OpenBSDの方が超安全じゃない？ごめん、あのプロジェクトを見たのは結構前だから。
FreeBSDは2019年までユーザーランドのASLRがなかったし、他の対策も含めてkASLRもまだない。セキュリティを気にする人には真剣なOSとは言えないよ。FreeBSDとセキュリティを求めるなら、Shawn WebbのHardenedBSDを使った方がいいよ。
いつもそういうやつがいるよね。君のお気に入りのディストリビューションが確実に安全だってのは素晴らしいことだよ。エクスプロイトが1桁少ないってことは、数千件程度になるんじゃないかな。オジマンディアスはGentooを使ってたし。
npmやPyPI、Cargoみたいな依存関係マネージャーに対するサプライチェーン攻撃には、すでにまあまあな解決策があるよ。数日以上古いパッケージバージョンだけをインストールするように設定するの。最近の目立った攻撃は、すべて1日以内に発見されてロールバックされたから、これをやってれば安全に攻撃を避けられたはず。これがデフォルトの動作になってもいいと思う。自己選択のベータテスターやセキュリティスキャナーの会社が、新しいパッケージのバージョンを1日試してから、こっちが使うようにすればいい。詳しくは: https://cooldowns.dev/
それで、セキュリティアップデートも遅れるの？多くの脆弱性は、気づかれるまで何年も放置されてるし、パッチが当てられるのも遅い。気づかれたら、そこでエクスプロイトの爆発が起きて、どこにでも興奮したエクスプロイターが現れる…遅れたアップデートに勇気づけられて。
こういうの、3ヶ月前のShow HNで見たやつにもっと合ってるかも。https://github.com/artifact-keeper アーティファクトマネージャー。自分が承認したものだけを手に入れる。必要なときに迅速なアップデートができて、安定したものを一貫して得られる。ちょっと設定のオーバーライドが必要だけど、簡単な作業だよ。自分でも似たようなツールを使ってたけど、これはいいプロジェクトだね。
個人的には、最も持続可能なモデルはLinuxディストリビューションやBSDポート、Homebrewのやり方だと思う。新しいライブラリを公開レジストリにプッシュするんじゃなくて、変更ごとにレビューされるパッケージスクリプトを書く感じね。
新しいプレイヤーで、継続的インテグレーションやコンテナビルドに入った人は、ビルドのたびにたくさんのパッケージで「最新」を引っ張ってないか確認してみて。私たちは、外部依存関係がすでに入ったベースコンテナを設定して、必要なときだけ明示的にアップデートするようにしてる。これで、最先端には少し遅れるかもしれないけど、ランダムなサプライチェーンの脆弱性が瞬時にグローバルに広がるリスクをかなり減らせるんだ。
これをやることで、CIのビルド時間や不安定な失敗も大幅に削減できるよ。
「ソフトウェアをインストールするのに1週間待て」ってのは通用しないよ。数ヶ月前に大規模な脆弱性がネットを襲ったけど、あれは1ヶ月以上待ってから実行されるタイミング攻撃だった。みんなが1週間待ち始めたら、攻撃者は2週間待つだけ。サイバー犯罪者はすぐに攻撃する必要はなくて、ただ攻撃するだけでいいんだ。（それに、タイポスクワッティングみたいな脆弱性クラスには大きな変化はないしね。）
だからクールダウン期間にはパッチの余地があるんだよね。
著者は「1週間待て」っていうのを、これらの特定の早期に公開された脆弱性の修正が書かれてパッチが配布されるための一回限りの待機として提案してたんじゃないかな。全てのアップデートを遅らせるための継続的な提案ではないと思う。でも、そうじゃなければ君に同意するよ。
君は記事を誤解してると思う。提案は、ソフトウェアが公開された後にインストールするまで1週間待てってことじゃない。今からの次の7日間、ただ待たないでってことだよ。おそらくこれらの脆弱性に対するパッチはないし、たとえあっても、もっと怖い脆弱性が発見される可能性があるから。
人気のあるパッケージは露出が多いからね。アーティファクトが公開されると、全世界がそれを見られる。できれば、バージョン間の差分をチェックする人がいるといいけど。遅延がなければ、誰も見たことのないエクスプロイトにやられる可能性もあるからね。
じゃあ、1ヶ月か2ヶ月待とうか。待機期間の目的は、新しいエクスプロイトのインストールを避けることが主だから、すでにインストールされているエクスプロイトの実行を防ぐためじゃないんだよね。
これはいつか起こる悪夢だったよ。パッケージの膨大な量と、それによるサプライチェーン攻撃の広大な攻撃面は、いつか必ず問題になるって分かってた。でも、便利すぎたんだよね。これについて警告したり、被害を抑えようとする人は、他のやり方を知らない人たちに叫ばれてた。「import antigravity」ってのは、やらないのが難しいくらい簡単だった。まあ、今はその「知る」部分に達してるってことかな。
そういえば、もし未知の攻撃ベクターを全部暴露した結果、世界中の国家情報機関のホルスターが空っぽになるとしたらどうなるんだろう？ただのアイデアなんだけど。基本的に、すべてをきれいにして、エクスプロイトを探している人たちが「スクラッチ」からやり直さなきゃいけなくなる。しかも「スクラッチ」は、役に立つソフトウェアがすべてファズテストされて、プロパティテストされて、正式に検証された場所になってる。もちろん、各国がまだ持っているものを最悪の敵にぶつけるギャップ期間を生き延びられればの話だけど。まあ、動物の骨でお互いを叩き合うこともできるしね。
ずっと能力ベースのセキュリティモデルが欲しかったんだ。実際、ここで議論したこともある。能力は、関連する権限を持つオブジェクトポインタみたいなもので、Unixのファイルディスクリプタのようなものだよね。私たちが持つべきは、- OSレベルの能力。起動したプログラムには、シェル（またはプログラムを起動した場所）から能力トークンが渡される。すべてのシステムコールは、最初の引数として能力を取る。だから、「open path /foo」はopen(cap, "/foo")になる。能力は、フェイクファイルシステム、実際のファイルシステムのブランチ、ネットワークファイルシステム、あるいは本当に何でも対応できる。プログラムは、自分がどんなサンドボックスにいるのかを知ることはできない。- ライブラリ/言語の能力。サードパーティのライブラリを取り込むとき、例えばnpmモジュールのように、そのライブラリにも能力が渡されるべきだ。インポート時か呼び出し元ごとに。プログラムのアドレス空間内のすべてのバイトに対して読み書きアクセスを持つべきじゃないし、私のコンピュータ上で私のように何でもできる権限を持つべきじゃない！質問は、「このコードの爆風半径はどれくらいか？」ってこと。使っているライブラリが悪意があるか脆弱な場合、どれだけのダメージが起こり得るかのために、健全なデフォルトが必要だ。lib::add(1, 2)が私のコンピュータ全体の持続的な侵害につながるべきじゃない。SeL4は、速くて効率的なOSレベルの能力を持っていて、何年も前からそれを実現している。すごくうまく機能してるし、多くの場合Linuxよりも速い。透明なサンドボックス化、ユーザーランドドライバー、IPC、セキュリティの改善などに非常に役立つ。LinuxをSeL4のプロセスとして実行することもできる。私は、Linuxデスクトップのすべての機能を持ちながら、SeL4のように動作するOSが欲しい。でも、残念ながら、私が求めるような言語レベルの能力を持つプログラミング言語はないと思う。Rustはすごく近いけど、サードパーティのクレートが信頼できない依存関係からのunsafeコードを呼び出すのを制限する方法が必要だ。Rustの長年の健全性バグも修正する必要があるし、能力ベースの標準ライブラリも必要だ。グローバルなopen() / listen() / などはもういらない。openat()とOSの他の部分の同等物だけでいい。LLMがどんどん良くなっていくなら、誰かが最初にやらない限り、数年後にはLLMを使ってこれらのものを作るつもりだ。現代のデスクトップOSのセキュリティは冗談みたいなものだよ。
サーバーサイドの技術をもうちょっと考えなきゃいけないかも。少なくともビルドプロセスには気を使った方がいいよね。
今日の騒ぎの後、またカーネルのRPMをやるのが楽しみだよ！シェルユーザーがいるサーバーが1台あって、先週「yum update」と「reboot -f」をやったんだけど、それで十分だったかな？ああ、また始まるのか！
誰か、copyfailのこととそれがNPMパッケージにどう関係しているのか教えてくれない？編集: わかった気がする。copyfailはカーネルのバグで、悪意のあるnpmパッケージがLinuxサーバーでrootアクセスを得ることができるんだよね？だから、パッチが当たっていないサーバーがある今が、攻撃者がNPMパッケージを狙う絶好のタイミングってことか。アドバイスは「カーネルをアップデートしろ」だけじゃなくて、まだ新しい関連の問題が見つかっているからなんだよね？
npmはLinuxで動くよ。
NPMのサプライチェーン攻撃はすごく早く広がるよ。もし人気のあるNPMパッケージが侵害されてcopy.failのエクスプロイトが含まれていたら、多くのシステムがroot権限の昇格に対して脆弱になるだろうね。
これで、自分がハッキングされたのかどうか気になってきた。ここ数週間、メインのMBPとiPhoneが1〜30秒の予期しないハングを示してるんだ。原因がわからない - メモリの圧迫でもCPUの負荷でもない。両方のデバイスで同じタイミングでこのもたつきが現れたのが心配なんだよね。
Ubuntu 26.04 LTSへのアップグレードは、新しいリリースの経験が数ヶ月できるまで待つことにしてる。Canonicalが大規模なDDOS攻撃を受けたばかりだし、そのトラフィックの中に他の攻撃が隠れている可能性もあるからね。
今回の脆弱性はかなり重要になりそうだね。どう対応するのが正解なんだろう？