3 ポイント 投稿者 GN⁺ 2024-06-03 | 1件のコメント | WhatsAppで共有
  • 今週初め、Spacesプラットフォームでsecretsに関する不正アクセスが検知され、一部のsecretsが外部からアクセスされた可能性があります
  • 初動対応として、secretsに含まれていた複数のHFトークンが失効され、対象ユーザーにはメールで案内が送信されました
  • ユーザーには、関連するkeyとtokenを再発行し、新しいデフォルトであるfine-grained access tokensへ移行することが推奨されます
  • Hugging Faceは外部のサイバーセキュリティ・フォレンジック専門家と調査を進めるとともに、セキュリティポリシーと手順も再検討中です
  • Spacesインフラには、org tokensの削除、KMS導入、流出トークンの検知・無効化強化が適用され、関係当局にも事案が報告されました

Spaces secretsへの不正アクセスとユーザー対応

  • Hugging Faceは、SpacesプラットフォームでSpaces secretsに関連する不正アクセスを検知しました
  • 一部のSpaces secretsが不正にアクセスされた可能性があります
  • 初期復旧の過程で、secretsに含まれていた複数のHF tokensが失効されました
    • トークンが失効されたユーザーには、すでにメールで案内が送られています
  • ユーザーには、keyまたはtokenを新たに発行することが推奨されます
  • HF tokensは、新しいデフォルトであるfine-grained access tokensへ移行することが推奨されます

Spacesインフラのセキュリティ強化と後続対応

  • Hugging Faceは、外部のサイバーセキュリティ・フォレンジック専門家とともに事案を調査し、セキュリティポリシーと手順を見直しています
  • ここ数日のあいだに、Spacesインフラのセキュリティが強化されました
    • org tokensを完全に削除し、追跡性と監査機能を高めました
    • Spaces secretsにキー管理サービス(KMS) を導入しました
    • 流出トークンを識別し、事前に無効化するシステム能力を強化・拡張しました
    • 全体的なセキュリティを改善しました
  • fine-grained access tokensが機能的同等性に到達した時点で、近いうちに“classic” read/write tokensを完全に廃止する計画です
  • 想定される関連事案の調査は継続しています
  • Hugging Faceは、この事案を法執行機関およびデータ保護当局にも報告しました
  • 問い合わせはsecurity@huggingface.coで受け付けています

1件のコメント

 
GN⁺ 2024-06-03
Hacker Newsのコメント
  • 2日前にセキュリティカンファレンスのスライドをざっと見たのですが、Jossef Harush Kadouriが、Hugging Faceのような場所のモデルを使うと、モデル作成者が自分のマシン上で任意のコードを実行できることを示していました。
    スライドが他の場所に上がっているかは分かりませんが、ファイルとして受け取ったものはここにあります: https://dro.pm/c.pdf (45MB) 188枚目のスライド
    その時は、モデル作成者だけでなく、Hugging Faceが裁判所命令を受けた場合やハッキングされた場合にも同じことが可能だ、という意味だとは気づいていませんでした。特に侵害にしばらく気づかない場合はなおさらです¹
    AI業界の外にいるので、こうしたモデルを自分で動かしたことはありませんが、業界がこの形式をこれほど早く標準化したことに驚きました。モデルファイルは大きな数値行列と少しのメタデータだと思っていたのですが、スライド186と195を見ると、モデルは実質的に何でもできるPythonスクリプトなので、標準化しやすかったのだと思います。各自がやりたいことをできるようにしておけば問題は回避されますが、それには相応のコストが伴います。
    ¹ https://www.verizon.com/business/resources/articles/s/how-to...によると、20%は数か月間侵害に気づかないそうです。もちろん状況や攻撃者の行動によります。
    • 「モデルファイルは大きな数値行列と少しのメタデータだと思っていた」という部分については、ONNX[1]はおおむねその形に近いです。
      ただし、すぐに直面する問題がユーザー定義のレイヤー/演算子とその推論ロジックです。サポートされている演算だけで実装する必要がありますが、現実的には難しい、または不可能な場合があります。あるいは実行時に演算子の実装を提供する必要があり、結局振り出しに戻ります。
      [1] https://onnx.ai/
    • だからホスト上でコードを実行できない**.safetensors**形式があるのでは?
    • 他の人も指摘しているように、これは形式次第です。このスレッドでまだ安全な側として言及されていない形式には、llama.cppと派生プロジェクトが使っているGGUFがあります。
      ほぼ「大きな数値行列と少しのメタデータ」に近い形式で、いくつかの脆弱性が見つかりパッチが当てられています。
      [1] https://www.databricks.com/blog/ggml-gguf-file-format-vulner...
    • 私の理解では、モデルがpickleでシリアライズ/デシリアライズされる場合にだけこの問題が起きます[0]。
      [0]: https://huggingface.co/docs/hub/en/security-pickle
    • dro.pmのリンクはまもなく期限切れになる予定です。一時リンクなので短いもので、もっと永続的なサービスを使うべきだったかもしれません。
      後から読む人のために発表動画を見つけました: https://m.youtube.com/watch?v=8XysLIq-e3s
  • 「彼らは疑っている」で始めるのは、あまりにも逃げ道を残した表現です。この種のコミュニケーションに入れる文としては不適切に見えます。
    • むしろかなり良かったと思います。通常この種の漏えい通知では、ハッカーが侵入した後に何をしたか「分からない」ため、「シークレット値にアクセスされた証拠はない」のように言います。
      Hugging Faceは少なくとも「おそらくシークレット値にアクセスされた可能性があるが確認はできない」と言ったわけで、より正直に見えます。
  • 「過去数日間でSpacesインフラのセキュリティを大幅に改善した」として、組織トークンの完全廃止、追跡性と監査機能の強化、Spacesのシークレット値用KMS導入、漏えいトークンの特定と先制的無効化の強化、全般的なセキュリティ改善を行ったと言っていますが、「数日」で終えるにはかなり大きな作業量です。
    こうした作業は本番反映前に、セキュリティ監査やペネトレーションテストのような、より時間のかかる手続きを伴うべきではないのでしょうか?
    • すでにしばらく進行中だった作業で、被害がすでに発生しているので今デプロイした、という可能性があるといいのですが。
    • 専任のセキュリティチームを含むSRE部門があるようなより大きな組織ならその通りですが、私の印象ではHugging Faceはまだその規模の組織ではないように思います。
  • 私のAnthropicキーが漏えいし、誰かが1万ドルの請求額を発生させました。Hugging Faceはこれを補償してくれるのでしょうか?
    • 私のOpenAIキーも漏えいし、誰かが使っているのを見つけました。幸い被害はずっと小さく、数ドル分のGPT-4程度で、当時私のアプリはそのモデルすら使っていませんでした。
      ほぼ間違いなくHF Spaceのシークレット値を通じて漏えいしたと思います。数日前、私のSpacesの一部が影響を受けたという警告メッセージを受け取りました。
    • そのキーが本当にSpaceのシークレット値だけに保存されていたと確信していますか?変数は公開で、.envファイルに保存したものも公開です。
    • クラウド提供プラットフォームでは、通常は支出の上限を設定できると思っていました。
  • 数週間前に私のOpenAIキーのいくつかが盗まれたことに気づきました。そのキーはHugging Face Spaceのシークレット値としてだけ有効化されていました。
    数日前に該当Spacesが侵害されたというメールを受け取ったので、この問題は少なくとも数週間前から続いていたようです。
  • 不適切に発生した費用をどう扱うかについての言及がありません。シークレット値にアクセスできたなら、APIを呼び出して費用を積み上げることができるのでは?
    それともこれは純粋にデータ/コードの窃取に関する問題なのでしょうか?
    • 両方あり得ます。私の場合、キーはOpenAI呼び出しに使われており、ほぼ間違いなくSpacesのシークレット値から漏えいしたと思います。
  • 「Space」って何ですか?
    • Hugging FaceのSpacesを略して呼んだものです。
      https://huggingface.co/docs/hub/en/spaces-overview
      フロントエンド/ポータルのように見え、Pythonで書かれていそうです。Djangoのようなものかもしれません。
    • ユーザーのコードを実行する仮想マシンです。
  • なぜHFは「シークレット値」を保存するのでしょう?
    公開鍵だけ保存して、ユーザーが秘密鍵を持ち、リクエストに署名する形ではだめなのでしょうか?
    • HFにホストされるアプリを作成し、OpenAIやAnthropicのような外部APIにアクセスできます。このときAPIキーがHFのシークレット値に保存されます。
    • 通常、ブラウザーセッション内で実際に動作させるには、何らかの形のトークンが必要です。今回の件は取り消す必要があったトークンに関するもののようで、パスワードに似ていますが完全に同じではありません。