しばらくは新しいソフトウェアをインストールしないほうがよいかもしれません
(xeiaso.net)- copy.fail 以降、Linuxカーネルの脆弱性が追加で公表された
- 現在は NPMサプライチェーン攻撃 が大きな被害を出しやすい時期だと評価されている
- ディストリビューションが提供する Linuxカーネルのパッチ は例外とすることが推奨されている
- それ以外については、約 1週間ほど 新しいソフトウェアのインストールを止めるほうがよい
- 投稿後に 事実関係や状況 が変わっている可能性があるため、誤りや不明確に見える部分があれば結論を出す前に連絡してほしいという断り書きが添えられている
1件のコメント
Hacker Newsの意見
これは、いつかは必ず起きる悪夢だった。パッケージの数が多すぎて、それだけ サプライチェーン攻撃の攻撃面 が巨大になり、いずれ皆に降りかかる問題だった
ただ、あまりにも便利だった。警告したり被害を減らそうとした人たちは、別のやり方を試した経験のない人たちに黙殺され、
"import antigravity"は手放すにはあまりに簡単すぎたいまや「代償を払う」段階に入ったように見える
コンパイラ、カーネルなども含め、ほぼすべてをソースからビルドしており、ビルドサーバー/インフラはインターネットに一切アクセスできず、変更を取り込む手順も決まっていた。関連する CVE は公開されるたびに精査し、自分たちに影響するか、どう緩和または対処するかを判断していた
その後移った会社では、ビルドがインターネットにアクセスでき、新バージョンが出るとすぐアップグレードしていた。最新のバグ修正を受けられるという理由で、人々はそれを良い実践だと考え、CVEレビューはセキュリティチームの担当だった
その次のスタートアップでは、いろいろな実践が混在していた。とても良い部分もあったが、CVE負債 も大きかった。たとえばサーバーにはセキュアブートと暗号化ディスクを適用しており、コンポーネント間通信の保護についてもかなり把握していた
皆、自分たちが正しくやっていると思っている。「頻繁にアップグレードする」人に、新しい問題を持ち込むリスクがあると納得させるのはほとんど不可能だ。業界にはより良い実践のセットが必要で、個人的には最初の会社の依存関係管理の方が優れていると思う。全体としてセキュリティ実践がしっかり根付いていて、製品も本当に安全だった
有用なソフトウェアがすべて ファジングテスト、プロパティテスト、形式検証を経た状態になり、脆弱性を探す全員がまたゼロから始めなければならなくなる、ということだ
もちろんその間に、各国が残っている手段を最悪の敵に投げつけ合う空白期間を私たちが耐え抜ける、という前提は必要だ。でなければ結局、動物の骨で殴り合うことになるのかもしれない
OSレベルでは、起動されたプログラムがシェルや起動元から権限トークンを受け取り、すべてのシステムコールが第1引数として権限を受け取るべきだ。つまり
"open path /foo"はopen(cap, "/foo")になる。この権限は、偽のファイルシステムでも、実ファイルシステムの一分岐でも、ネットワークファイルシステムでも何でもよく、プログラムは自分がどのサンドボックス内にいるのか知る必要がないライブラリ/言語レベルでも、npmモジュールのようなサードパーティライブラリを取り込むとき、import時や呼び出し箇所ごとに権限を渡すべきだ。そのライブラリが自分のプログラムのアドレス空間内の全バイトに読み書きアクセスを持ってはならないし、自分のコンピュータ上で自分になりすまして何でもできてはならない。中心的な問いは「このコードの 爆発半径 はどこまでか？」だ。使っているライブラリが悪意あるものだったり脆弱だったりしたとき、被害規模について妥当なデフォルトが必要だ。
lib::add(1, 2)の呼び出しが、自分のコンピュータ全体の永続的侵害につながってはならないSeL4 は高速かつ効率的なOSレベルの権限をずっと前から提供しており、うまく機能している。多くの場合Linuxより高速で、透過的サンドボクシング、ユーザー空間ドライバ、プロセス間通信、セキュリティ改善などに非常に役立つ。LinuxをSeL4上のプロセスとして動かすこともできる。Linuxデスクトップの全機能を持ちながら、SeL4のように動作するOSが欲しい
残念ながら、自分が望む形の言語レベルの権限を持つプログラミング言語は存在しないようだ。Rustはかなり近いが、サードパーティcrateが
unsafeコードを一切呼べないよう制限する方法が必要だ。信頼していない依存関係が呼ぶunsafeも含めてだ。Rustの古い健全性バグも修正されるべきで、権限ベースの標準ライブラリも必要だ。グローバルなopen()/listen()のようなものは消えるべきで、openat()やOSの他部分に対応する同等の形だけがあるべきだLLMがこのまま改善し続けるなら、数年以内に誰も先に作らなければ、LLMにこれを全部作らせるつもりだ。現代のデスクトップOSのセキュリティは冗談みたいなものだ
コードにも 衛生文化 が必要で、これは多くの文化圏が食べ物に対して発達させてきた規範とそれほど違わない。粗いヒューリスティクスの組み合わせではあるが、「うわっ」という感覚が何十億人もの命を救っている
いまでは依存関係への露出をこれまで以上に減らしており、特に数百行で実装できるものではなおさらだ。これはまさに パラダイムシフト だ
「ソフトウェアのインストールを1週間待て」というやり方は通用しない。つい数か月前にも、大規模な脆弱性がWebを襲ったが、それは1か月以上潜伏してから実行された 時間差攻撃 だった
皆が1週間待ち始めたら、攻撃者は2週間待つだけだ。サイバー犯罪者は即座に悪用する必要はなく、最終的に悪用できればよい。タイポスクワッティングのような多くの脆弱性タイプも、この方法では変わらない
これらの脆弱性へのパッチがまだない可能性が高く、仮にあっても、ほどなくさらに恐ろしい脆弱性が見つかる可能性が高いからだ
しかし遅延がまったくなければ、まだ誰にも見つかっていない エクスプロイト にやられる可能性がある
しかも、こうした侵害の発見は、実際に悪用されたかどうかにまったく依存していなかった。だから「皆が1週間待てば攻撃者は2週間待つ」という話が理解できない
別の選択肢として、セキュリティにYOLO的なアプローチを取らない FreeBSD のようなOSへ移ることもできる
セキュリティ修正が調整もなくFreeBSDカーネルにそのまま投げ込まれることはない。FreeBSDセキュリティチームを経由し、パッチがsrcツリーに入った後、数分以内にFreeBSD Updateと15.0-RELEASE向けpkgbase経由でバイナリアップデートが配布される
だいたいSlackに「パッチをpushした」というメッセージが出るまで数秒、パッチのアップロードに10〜30秒、ミラー同期に最大1分ほどかかる
公平を期すと、自分の報告は中核コンポーネントではないものに関するもので、悪用も簡単ではなかったが、Debian、OpenBSD、SUSE、Gentoo はいずれも1週間以内に修正した https://www.maxchernoff.ca/p/luatex-vulnerabilities#timeline
だからといって、単一の些細な報告処理だけでOS全体を評価しようという意味ではない。自分が見た他のあらゆる点では、FreeBSDはセキュリティ報告をかなり真剣に扱っているように思えるからだ。ただ、同じ理屈はLinuxカーネルのバグにも当てはまる。そういう形でパッチ管理がひどくなることは、Linuxでもかなり稀だ
セキュリティより使いやすさを好む傾向がある。有名な例はここにある: https://vez.mrsk.me/freebsd-defaults
プロジェクトへの貢献には感謝しているが、こうした悪いデフォルトがある限り、良心的に人へ移行を勧めることはできない
FreeBSDでセキュリティを求めるなら、Shawn WebbのHardenedBSDを使う方がよい
セキュリティ専門家でさえ、いまや私たちの世界がとてつもなく 脆い均衡 の上にあることを受け入れるべきだ。人々はこれを本当に過小評価していると思う
ITの世界だけでなく、世界全体が数多くの非常に脆い均衡の上に築かれている。セキュリティエクスプロイトは常に存在する。ソフトウェアだけでなく現実世界でも同じだ。誰かがセキュリティカンファレンスにこっそり入り込んだこともあったし、それもただのYouTuberだった。もちろん超高セキュリティなイベントではなかったが、思い浮かんだ例がそれだった。基本的に、多くの場合セキュリティを回避するのは本当に簡単だ
言いたいのは、根本的にこの世界は、少なくとも大半の人が悪用しないからこそ機能しているということだ。人間社会は常にそうやって機能してきたし、これからもそうである可能性が高い
Max FoshというYouTuberがInternational Security Expoに立て続けに入り込んだのだったと思う。英国では https://www.youtube.com/watch?v=qM3imMiERdU、米国では https://www.youtube.com/watch?v=NmgLwxK8TvA で、それぞれ偽名として「Rob Banks」と「Nick Everything」を使っていた
セキュリティ文化を少し勉強したことがあるが、ほとんどは一方にセキュリティ、他方に利便性/アクセス性がある スライディングスケール に帰着する。安全であるほどアクセスしにくくなり、その逆もまた然りだ
npm、PyPI、Cargo のような依存関係マネージャーに対するサプライチェーン攻撃には、すでにかなり良い解決策がある。パッケージのバージョンが数日以上経過したものしかインストールしないよう設定することだ
最近の大きな攻撃はどれも1日以内に発見されて差し戻されていたので、そうしていれば安全に回避できていたはずだ。この挙動はデフォルトであるべきだ。自ら志願したベータテスターやセキュリティスキャナー企業に、最新のパッケージバージョンを1日ほど先に試してもらえばよい。方法はここにある: https://cooldowns.dev/
成果物マネージャー だ。承認したものだけを取得できるようにしてくれる。必要なときは素早く更新し、必要なときは一貫して検証済みの安定版を使える。多少の設定上書きは必要だが、簡単な作業だ
同じ目的の雑なツールを自作して使っていたことがあるが、これは良いプロジェクトだ
もちろん企業の外では自然にはなかなか機能しない
ひとたび見つかれば、すぐにエクスプロイトの爆発が起き、更新の遅延は興奮した攻撃者により多くの時間を与える
もう1つのモデルは、ソースファイルだけを配布するPerlのCPANだ
継続的インテグレーションとコンテナ化ビルドを比較的最近導入した人たちは、毎回のビルドで複数パッケージから
latestを引いてきていないか、システムを確認した方がいい私たちは、外部依存関係を全部入れたベースコンテナを作っておき、更新時期だと判断したときにだけ明示的に更新している
そのため最先端からは少し遅れるかもしれないが、ランダムな サプライチェーン脆弱性 が即座に世界中へ配布されるリスクは、はるかに小さくて済む
積極的に有害なオピニオン記事だ。論理を理解するのが難しい
copyfailとdirtyfragの脆弱性が実際にどれほど古いか確認するのに45秒もかからない。記事を読むより長いくらいだ。Dirtyfragは2017年までさかのぼるシステムにも関係しうる
影響を受けるのは「新しい」ソフトウェアではない。そして実際、古いソフトウェアの方が問題を見つける時間はずっと長かったのだから、状況はより悪い
いつか誰かが、OSからアプリケーションまで スタック全体 を証明携行コードによるアップグレードで作り直すだろう
信頼できるコードを実行する唯一の方法は、証明とコードを共同設計し、共同構築することだ
これはソフトウェアにだけ当てはまる話ではなく、実際にはほとんどあらゆるものに当てはまる
どこで読んだのかは覚えていないが、結局は 必要と欲求 の違いに帰着する
新車を買うか中古車を買うか、高級掃除機を買うか基本モデルを買うかを決めるときに、このルールを使ってきた。ピカピカの新しい機器、技術スタックへ何か新しいものを持ち込むこと、新しい技術スタックを選ぶことにも同じことが言える
copyfailが何で、NPMパッケージとどうつながるのか理解する助けが欲しい
整理すると、copyfailは悪意あるnpmパッケージがLinuxサーバー上でroot権限を得られるようにする カーネルバグ のようだ
つまり、まだパッチが当たっていないサーバーが存在するいまこそ、攻撃者がNPMパッケージを狙うには絶好のタイミング、ということか
助言が単に「カーネルを更新しろ」ではないのは、関連する新たな問題がまだ次々に見つかっているからなのか？
人気のNPMパッケージが侵害され、copy.failエクスプロイトを含んでいたら、多くのシステムがroot権限昇格に脆弱になるだろう