Researchers Hack Snowflake PostgreSQL Database to Gain Full Server-Level Code Execution
2026/10/19 gbhackers — Snowflake が管理する PostgreSQL のセキュリティ・テストにより判明したのは、権限が制限されたデータベース・ロールを悪用することで、データベースが稼働するサーバの制御権を奪われる可能性があることだ。研究者たちが実証したのは、PostgreSQL に組み込まれた複数の機能を連鎖的に利用することで、オペレーティング・システムのコマンドを実行できることだ。Snowflake は、SQL を介したコマンド実行やファイル・アクセスといった、一般的な手段をブロックしていたが、これらの制限を回避する経路が存在していた。
この発見が示すのは、マネージド・クラウド・サービスにおいて、限定的な権限の組み合わせが重大なリスクにつながる可能性である。研究者によると、この権限昇格の連鎖は、”snowflake_admin” という非スーパーユーザー・アカウントから始まった。
重要な権限となったのは、アカウントによるロールの作成と管理を可能にする CREATEROLE である。この権限だけではデータベースを完全に制御できないが、今回のケースにおいては、データベースが信頼する他の機能を経由して、権限を昇格させる経路を開くことが可能となった。
Varonis Threat Labs の研究者たちは、この権限昇格の連鎖を発見し、Snowflake に報告した。
Varonis によると、Snowflake は調査結果の公開前に問題を修正しており、Snowflake Postgres を利用する顧客にとって、今回の発見に関連する対策の実施は不要である。研究チームが、この問題を最初に報告したのは 2026年5月31日であり、10月17日に調査結果を公開した。
研究者が Snowflake PostgreSQL データベースへの侵入に成功
最初の段階で利用されたのは CREATEROLE 権限である。この権限を悪用することで、研究者が起点となるアカウントに付与したのは、2 つの組み込みロールである “pg_read_all_data” と “pg_write_all_data” だった。
これらのロールは、データベースのテーブルとシステム・カタログに対する広範なアクセス権限を提供する。このアクセス権限により、研究者が可能にしたのは、スケジュールされたジョブを実行する PostgreSQL の拡張機能 “pg_cron” のエントリに対する変更だった。
研究者はスケジュールされたジョブを変更し、高い権限を持つ “postgres” アカウントとして実行されるようにした。その結果、このジョブが実行されると、SECURITY DEFINER 関数が作成された。
.webp)
この種の関数は、呼び出し元のユーザーではなく、関数の所有者の権限で実行される。研究者は、この関数を利用することで、Snowflake がブロックしていた直接的なロール変更を行わずに、PostgreSQL のスーパーユーザー権限を取得した。
ただし、データベース・レベルのアクセス権限を取得しただけでは、サーバの制御権限を取得したことにはならない。Snowflake は、サーバ上のファイルの読み取り／システム設定の変更／SQL を介したプログラムの実行といった、一般的な手段をブロックしていた。
しかし、研究者たちが発見したのは、PostgreSQL の “internal” 言語を使用することで、サーバ・ソフトウェア内に存在する C 言語の関数に、新しいデータベース関数名を紐づけられることだ。これにより、ブロックされていたファイル読み取り関数とファイル書き込み関数を、別の名前で再び利用できるようになった。
ファイルへのアクセス権限を取得した研究チームは、PostgreSQL のラージ・オブジェクト機能を利用して設定ファイルに書き込んだ。それにより変更されたのは、完了した Write-Ahead Logging (WAL) セグメントをアーカイブする際に、PostgreSQL のシェルコマンドを実行する “archive_command” 設定である。
WAL とは、データベースの変更内容がデータファイルに完全に書き込まれる前に、その変更を記録する仕組みである。設定されたコマンドが実行された結果、研究者は “postgres” システム・アカウントの権限で、オペレーティング・システムのコマンドを実行することに成功した。
この発見が示すのは、関連する機能が別の経路から利用可能な場合において、SQL からオペレーティング・システムの機能を呼び出す既知の手段をブロックするだけでは、不十分となる可能性である。
マネージド・データベースでは、サービス提供者がサーバとオペレーティング・システムを管理する一方で、データベース・ロールの割り当ては顧客が決定するため、この問題は重要である。
データベースからサーバへのアクセス権限の拡大につながるリスクとしては、PostgreSQL のコード実行の脆弱性や、pgAdmin のシェルコマンド実行の脆弱性などが、他の環境で確認されている。
想定される影響と対応
攻撃者が同様のアクセス権限を取得した場合には、データベース・ファイルの変更／破壊や、復旧処理の妨害、ローカルログの改ざんなどが引き起こされる恐れがある。
その一方で、オペレーティング・システム・レベルの操作は、通常の SQL クエリを経由しない場合があるため、データベースの監査記録だけでは活動の全容を把握できない可能性がある。
Varonis によると、実証された操作は、研究者自身のシングル・テナントのテスト環境内に限定されていた。報告書には、Snowflake の顧客データにアクセスしたとの記載はない。
.webp)
Snowflake は調査結果を公開する前に、サーバ側での権限昇格の連鎖に対処した。報告書によると、同社は 2026年6月1日に脆弱性の報告を受領したことを認め、6月9日には Snowflake Postgres の仮想マシン内でのローカル・コード実行が、セキュリティ境界を越えることを確認した。
研究者が指摘するのは、今回の発見は単一のマルウェアに関するものではなく、PostgreSQL の複数の動作を連鎖させたものである点だ。PostgreSQL に関連する別のコード実行リスクについては、GBHackers が報じた Appsmith PostgreSQL のリモートコード実行の脆弱性も参考になる。
独自に PostgreSQL サーバを運用する組織に対して、研究者が推奨するのは、CREATEROLE を高リスクの権限として扱い、必要な場合を除いてアプリケーション・アカウントから削除することだ。
管理者にとって必要なことは、ロールの権限付与／スケジュールされた “pg_cron” ジョブ／SECURITY DEFINER 関数について、予期しない変更がないことの確認である。
さらに、”internal” 言語または C 言語の関数を作成できるユーザーの制限／データベース設定ファイルの保護／不要なネットワーク・アクセスとデータベース・サービスの分離も必要となる。
侵害の痕跡 (IoC)
| IoC type | Value |
|---|---|
| File hashes | None disclosed |
| Domains or IP addresses | None disclosed |
| Malware names | None disclosed |
注： IP アドレスとドメインは、意図しない名前解決やハイパーリンク化を防止するため、意図的に無効化された表記 (例：[.]) が使用されている。元の表記に戻す操作は、MISP、VirusTotal、SIEM など、管理された脅威インテリジェンスプラットフォーム内でのみ実施すること。
この記事は、クラウド型データベース管理基盤である Snowflake Postgres の権限昇格および不具合の連鎖させる攻撃について解説するものです。ロール作成権限の付与や内部関数の紐付け処理が背景に存在します。影響として、スーパーユーザー権限の不正取得／基盤システム上での任意コマンド実行が生じる恐れがあります。対応策として、運用側での管理権限の厳格化／定期ジョブや関数の定義変更監視が求められます。
You must be logged in to post a comment.