本文へスキップ
MameTechNews
バックエンド

BuildKit、共有キャッシュ経由で別イメージの層をすり替える欠陥を修正

## POINTS

  • 影響はBuildKit 0.33.0まで。0.33.1以降で修正され、深刻度はCVSS 4.0で7.5。
  • 共有キャッシュが条件。stargzを無効にするだけでは回避にならず、通常のスナップショッターも対象。
  • 信頼できないイメージは別デーモンか一時ビルダーで扱い、処理後にキャッシュを破棄する。

BuildKitのセキュリティ告知GHSA-f2v9-hprr-32q3(9月30日公開)は、イメージ層のDiffIDを検証しないキャッシュ汚染を高深刻度(CVSS 4.0で7.5)としている。悪意あるイメージが、別イメージのDiffIDを宣言しながら中身を変えていても、影響を受ける版は宣言されたIDからキャッシュとスナップショットの識別子を作ってしまう。

共有または永続キャッシュを持つBuildKitデーモンが、その悪意あるイメージを先に処理したあとで、被害側イメージを使うビルドが走ると、攻撃者の層がベースイメージとしてマウントされうる。例として/bin/shのようなよく実行されるパスの差し替えが挙がり、ビルドへマウントした秘密の読み取り、他のビルドリソースへのアクセス、成果物の改変、ビルドの停止につながりうるとされる。通常のスナップショッターに加え、stargzのような遅延取得も対象で、stargzを切るだけでは回避にならない。

告知の対象バージョンは0.33.0以下、修正済みは0.33.1以上。回避策は、信頼できるビルドと信頼できないビルドでデーモンのキャッシュを共有しないこと。信頼できないイメージは隔離したデーモンか一時ビルダーで扱い、処理後にキャッシュを捨てる。

Docker Buildxや共有のリモートBuildKitを、社外イメージと社内の秘密つきビルドで併用しているなら、先にバージョンを確認する。キャッシュを分けたまま古いデーモンを残すと、一度入った層が後続のベースになりうる。上げたあとも、秘密をマウントするジョブの実行履歴に見慣れないベースがないかを見る。