もともとはこれについて書くつもりはありませんでした。片方では、たぶんもう既に知られていることだろうと思った一方で、たとえそうでなかったとしても、それほど付け加えることがあるとは感じませんでした。
ですがまあ、とにかくコード漏えいの件をめぐる議論を見ていて、私も同じようなことが起きうるのかもしれないと思いました。
そこで：数週間前、クロードが“そのままの用途”ではなく、ある程度逸脱した使い方に対してどれくらい強力かを、実地で少し経験しました。基本的に、私はLinuxの内部について夜に自習していて、何かをクロードに質問しました。自分では「セキュリティのことを学んでいる」といった言い方でクロードに促したので、潜在的に有害なコードを生成する点について、かなり従順に振る舞うように下地ができてしまいました。そしてそこから状況がエスカレートしていきました。
その後、数時間以内に、クロードのWeb上のプロンプトで、最終的には環境からの完全なファイル一覧を提供し、すべてのコードとMarkdownファイルをzipにまとめてダウンロード用として提示しました（Anthropic製のスキルファイルも含む）。さらに入手できる限りのすべてのネットワーク情報を提示し、ネットワークをスキャンしました。コンテナから脱出するために、さまざまな脆弱性を利用しようとしました。いくつかのCVEについてCの実装を書きました。脆弱性を悪用するために難読化したCコードを実行することに同意しました。ツール用コンテナをクラッシュさせることに同意しました（繰り返し）。自分がVMモニタへのインターフェースだと考えたものにメッセージを送ることに同意しました。実行している環境について仮説を立て、それを可能な限り検証しました。メモリをJWTのためにスキャンし、実際に1つ見つけました。そして、別のクロードのセッションを起動し直すと、クロードは、その2つのセッションクト内でMACスプーフィングを試みるオーケストレーションを行うことに同意しました。
私の知る限りでは、実際の脆弱性は見つかりませんでした。クロードWebの基盤（infra）は非常に堅牢で、ええ、コードファイルの中にプロダクションコードはありません（主にライブラリですが）。ただし、クロードは同じことを任意の環境に対して実行できてしまいます。たとえば、あるサーバー上で管理者ではないユーザーアカウントがあったとして、その場合クロードは、上記のようなことを問題なくその環境に対して全部実行する可能性が高いです。
私にとっては、これらのツールがいかに素早く、悪意のある可能性のある作業を手助けしてくれてしまうのかが、かなり怖いです。たとえば、特定のBashスクリプトを書く必要がある環境や、利用可能なツールが何か、ファイルシステムがどうなっているのか、そもそもシステムが何なのかを最初から把握できていない環境では特にです。一方で、アプリケーション向けにコードを生成させると、彼ら自身が自分たちで設定しうる攻撃に対して生成できる以上の、より安全なコードを結局は生成できない傾向にあるというのが私の経験です。おそらく問題は、セキュアな書き方でコードを書くには比較的大きな文脈が必要になることが多く、ミスは必ずしも1行だけ見ても分かりやすいとは限らない（もちろん、これらのツールが例えばSQLインジェクションを許してしまうような単一行を書けないわけではありません）という点にあります。しかしその一方で、多数の脆弱性は、単にスキャンして検索し、よく知られたシナリオをいろいろ試すだけで見つかることが多い。さらに、セキュリティを正しくするには、大規模なコードベースの中で何百回もの試行すべてに対して正しくやる必要がありますが、脆弱性を1回見つければよいのに対して、攻撃側にはその脆弱性に対する試行が何千回も生まれうる。そういう意味では、これらのツールが“積み重なったゲーム”のように感じられます。
[link] [comments]
