「マネージド」という境界線は壁ではなかった
Supabase、Neon、Amazon AuroraのようなマネージドPostgreSQLプロバイダーは、顧客に強力な管理権限を提供しますが、真のsuperuser権限は与えません。彼らの目的は、ユーザーが基盤となるホストや他の顧客に影響を与えることなくデータベースを制御できる、安全なマルチテナント環境を提供することです。
プロバイダーは、カスタム拡張機能やフックを導入することでこれを実現しています。これらのレイヤーは、たとえ顧客向けの最高権限であっても、ファイルシステムに関わるような危険な操作をインターセプトしてブロックします。例えば、プロバイダーはサーバーのディスクにラージオブジェクトを書き込むために設計されたネイティブなPostgreSQL関数であるlo_exportをブロックすることがあります。
しかし、このカスタム制限レイヤーは誤った安心感を生む可能性があります。ガードレールが機能そのものではなくコマンドの「名前」のみをチェックしている場合、ユーザーはブロックを回避できてしまいます。内部のC言語関数エイリアスを監視されていない新しい名前で再登録することでブロックリストをすり抜け、本来制限されているはずの機能を呼び出すことが可能になります。この根本的な見落としが、重大な脆弱性の基礎となりました。
フィルターをすり抜けた新しい名前
報告されたバイパスは、名前ベースのフィルタリングにおける重大な死角を突いたものでした。PostgreSQLのlo_export関数は、データベースのラージオブジェクトをサーバーのファイルに直接書き込みます。マネージドプロバイダーはこの危険性を認識しており、通常はlo_exportを名前でブロックし、強力な顧客ロールであっても実行できないようにしています。
あるセキュリティ研究者が、このガードレールを回避する方法を実証しました。彼らはPostgreSQLのLANGUAGE internalメカニズムを使用して、基盤となる内部ルーチンへのアクセスを再作成しました。これにより、ブロックされたlo_exportと全く同じバックエンドのC言語実装を指す「監視されていない名前」を持つ新しい関数を定義することができました。
この手法は、危険な機能を別のラベルの下で効果的に複製し、プロバイダーのセキュリティ拡張をバイパスするものです。このエイリアス化された関数が利用可能になると、研究者はデータベースサーバーのディスクに任意のファイルを書き込むことができました。
この脆弱性は、名前ベースのフィルタリングのみに依存するセキュリティモデルの根本的な弱点を浮き彫りにしています。別名であっても同じ基盤実装を指す可能性があるため、ラベルをチェックするだけでは機能を制御したことにはなりません。プロバイダーの拡張機能は「lo_export」という単語をブロックしていましたが、サーバーにファイルを書き込むという「アクション」をブロックしていなかったため、重大な設計上の欠陥が放置されていました。
SQL権限からホストレベルのコード実行へ
複製されたlo_export関数は、ブロックされていないエイリアスとして動作し、重要なプリミティブを提供しました。それは、PostgreSQLホストに任意のファイルを書き込む能力です。攻撃者はこれを利用して、コンパイル済みの共有ライブラリ（.soファイル）をサーバーのディスクに配置しました。
悪意のあるライブラリを配置した後、次のステップはそれをPostgreSQLのC言語関数として登録することでした。これはCREATE FUNCTION ... LANGUAGE Cを通じて行われ、PostgreSQLに対して共有ライブラリから特定の関数をロードし、データベースのSQL環境に直接公開するよう指示します。
攻撃者が単純なSQLクエリを通じてこの新しく登録されたC言語関数を呼び出すと、データベースは攻撃者の任意のコードを実行しました。重要なのは、このコードがデータベースホスト上のPostgreSQLプロセス自体のオペレーティングシステム権限で実行されたという点です。これはrootアクセスではなく、またインスタンスは通常分離されているため、他の顧客のデータへのアクセスが自動的に許可されるわけではありません。
しかし、ホストでの実行は重要な足がかりとなります。これによりサーバー上での永続性が確保され、包括的なシステム列挙が可能になり、プロバイダーのインフラストラクチャ内でのラテラルムーブメント（横展開）の試みを容易にする可能性があります。深刻度は、各マネージドサービスの特定の分離メカニズムとネットワーク構成に大きく依存します。詳細な技術的分析については、「Breaking the PostgreSQL Superuser Guardrails: Attacking Security-Hardening Extensions」を参照してください。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
プロバイダーは販売する境界を保護しなければならない
Supabaseは迅速に対応し、4つの重大な問題に対するパッチを報告しました。他のプロバイダーは対応が遅かったり、公開された回答が不明確だったりした一方、PostgreSQLのコアチームは、PostgreSQLのセキュリティモデルはsuperuserが内部関数を制御することを前提としていると主張し、責任をサービスプロバイダーに明確に帰しました。
より深い洞察を求める読者は、Mehmet Ince氏の基礎研究「Breaking the PostgreSQL Superuser Guardrails」を参照すべきです。supautilsプロジェクトも重要なリファレンスを提供しており、これに加えて、これらの教訓を反映したSupabaseのロールとサポートされていない操作に関する詳細なドキュメントも参考になります。
このインシデントはプロバイダーにとって厳しい教訓となります。危険な操作を名前でブロックするだけでは不十分です。堅牢なセキュリティには以下が必要です。 - 内部関数およびC言語バインディングに対する厳格な制御 - カタログ権限の細心の管理 - より強力なOSレベルの分離
これらの対策は、単なる長いブロックリストではなく、プロバイダーが販売する管理境界を保護するために不可欠です。クラウドPostgreSQLの整合性は、プロバイダーが約束した境界を強制することにかかっています。
よくある質問
マネージドPostgreSQLの脆弱性とは何でしたか？
研究者が、プロバイダーのフィルターでブロックされていない名前で危険なPostgreSQL内部関数を登録することにより、プロバイダーの制限を回避しました。
この欠陥によって他の顧客のデータベースの内容が露出しましたか？
自動的には露出していません。実証されたエスカレーションでは、データベースホスト上のPostgreSQLオペレーティングシステムユーザーとしてコードが実行されましたが、これは他のテナントのデータへの即時アクセスではなく、足がかりを作成するものでした。
これはPostgreSQLのコアの脆弱性でしたか？
PostgreSQLのセキュリティチームは、これをプロバイダー側の問題であると特徴づけました。マネージドサービスは、自らが課す権限制限を安全に強制しなければなりません。
マネージドPostgreSQLプロバイダーは何を変更すべきですか？
危険な内部関数およびC言語関数のバインディングを制限し、カタログ権限を強化し、オペレーティングシステムレベルでデータベースプロセスを分離すべきです。