Lakebase Postgresの開示ケーススタディ
によって Aaron Kobayashi, Mehmet D. Ince, Anurag Srivastava 、 Alexey Kondratov による投稿
私たちがこれまで行ってきた優れたセキュリティ投資のいくつかは、ツールやスキャナーではなく、信頼関係への投資でした。Databricksがバグバウンティ（バグ報奨金）プログラムを運営しているのは、プラットフォームの脆弱な部分を特定する最も迅速な方法が、才能と好奇心にあふれる人々にそれらを探してもらうことだからです。そして、彼らが何かを発見した際には、誠意ある報告に対して誠意ある対応で応えることを大切にしています。ほとんどの報告は、誰かがバグを見つけ、私たちがそれを修正し、双方が次のステップに進むという、静かなやり取りで終わります。
しかし、ごく稀に、そうした報告の1つが本当に素晴らしいストーリーへと発展することがあります。今回ご紹介するのは、まさにそのようなお話です。
数週間前、外部の研究者であるMehmet Ince氏が、Lakebase PostgresやNeonを含むマネージドPostgresプラットフォームに搭載されているPostgres拡張機能におけるメモリ安全性のバグを指摘してくれました。この記事で取り上げる価値があると考えた理由は、バグそのものだけではありません。そのバグを巡って起きた一連の出来事、つまり、当社の検知システムが同氏のテストをどのように捉えたのか、いかに迅速にお客様を保護できたのか、および最終的に根本的な修正が本来あるべき場所（当社だけでなく、同じ拡張機能を利用するすべての人のためのオープンソースコミュニティ）にどのように還元されたのかという点にあります。
セキュリティチームを率いている方、マネージドなオープンソースインフラを運用している方、あるいは研究者とベンダーの健全な相互作用が双方の視点からどのように行われるのかに興味がある方にとって、この記事は非常に役立つはずです。Mehmet氏は、自身のブログで技術的なエクスプロイトの詳細なストーリーを公開しています。ここでは、私たちはそのコラボレーション（協働）についてお話ししたいと思います。
| Mehmet氏のブログでは、別のプラットフォームにおける顧客間データ漏洩について言及されています。Databricksは、コンピューティングインスタンス間に強力なセキュリティ境界を提供するmicroVMアーキテクチャ上でLakebase PostgresおよびNeonを実行しています。Mehmet氏のエクスプロイトによるDatabricksへの顧客間での影響は発生していません。 |
|---|
Postgresの拡張機能エコシステムは、その人気の大きな原動力となっています。ベンダーによってサポート状況は異なりますが、お客様はマネージドプロバイダーが最も広く使われているコアおよびサードパーティのオプションをサポートすることを期待しています。その1つが、地理空間ツールキットであるPostGISです。PostGISの内部には、address_standardizerと呼ばれる、非構造化住所（例：123 Main St）を正規化された形式に変換する、控えめながらも重要な拡張機能が含まれています。
Mehmet氏は、address_standardizerに古典的なメモリ安全性の欠陥があることを発見しました。呼び出し元が完全に制御できる値（呼び出し元が指定できる文法「ルール」の一部）が、境界値チェックなしで固定サイズの内部配列のインデックスとして使用されていたのです。範囲外の値を入力すると、境界外メモリへのアクセスが発生します。
マネージドPostgresサービスにおいて重要なのは、誰がその機能にアクセスできるかという点です。address_standardizerは、通常のテナントがインストールして使用できる拡張機能のセットに含まれています。そのため、このバグはアクセスするために特別な権限を必要とするものではありませんでした。通常の顧客ロールがこの関数を呼び出し、脆弱なコードパスに到達することが可能だったのです。これこそが、見過ごされがちな静かなバグを、プラットフォームチームが真剣に取り組むべき重大な問題へと変える要因です。
ここでは、エクスプロイトの詳細についての説明を意図的に最小限に留めています。Mehmet氏のディープダイブ記事では、その仕組みが適切に解説されており、要約するよりもそちらをお読みいただく方が理解が深まります。
Mehmet D. Ince 著
このストーリーは、脆弱性調査として始まったわけではありません。今年の春、社内会議の中で、私のチームからいくつかのPostgreSQLインスタンスをマネージドプロバイダーに移行できないかという質問がありました。約50名のエンジニアを擁する欧州の脅威インテリジェンス企業であるPRODAFTのCTOとして、私の責任の1つは、お客様に可能な限り安全なサービスを提供することです。
私たちは10年以上にわたり自社でPostgreSQLを運用してきましたが、マネージドPostgresプロバイダーがセキュリティの観点からどのようにこれらのサービスを提供しているかを適切にレビューしたことはありませんでした。私は2000年代初頭から脆弱性調査を行っているため、新しい技術をスタックに追加する際に伴うリスクをより深く理解するために、常に少しの時間を割いてセキュリティ調査を行うようにしています。案の定、私の「簡単なレビュー」は、誰かの受信トレイに重大な脆弱性レポートを届ける結果になる傾向があります。染み付いた習慣を変えるのは難しいものです。
調査を始めて数日後、ほぼすべてのプロバイダーがほぼ同じPostgres拡張機能を搭載していることに気づきました。広くデプロイされている拡張機能におけるメモリ破損の脆弱性は、実質的にPostgreSQL自体のメモリ破損の脆弱性と同じです。そこで私は、事実上どこでも利用可能な小さなPostGIS拡張機能であるaddress_standardizerをターゲットに選びました。
ある月曜日の夕方7時頃（ここロンドンにて）、Aaronから思いがけずメールが届き、Neonの本番環境のアラームをトリガーしたアクティビティが私によるものかどうか尋ねられました。私は、小さな無害な拡張機能にある単一の単純なバグが、本当にそこで特権昇格の経路を露呈させ得るのかを確かめるため、動作するエクスプロイトをNeon PostgreSQLインスタンスに移植する作業を行っていました。動作するPoCは手元にありましたが、私は彼にスクリーンショットだけを送りました。その1枚のスクリーンショットだけで、彼は行動を開始するのに十分だったのです！
私は20年以上にわたり、ベンダーに対して責任ある脆弱性の開示を行ってきましたが、これほど長い年月を経てもなお、適切な連絡先を見つけるために多くの時間を費やすことなく、発見した事項の影響やリスクを説明することは依然として困難です。このように研究者に積極的にアプローチし、迅速な対応をとってくれたAaronとDatabricksのセキュリティチームには、心から敬意を表します！
詳細については、Mehmet氏の投稿を参照してください。
私たちから見れば、これは協調的な脆弱性開示が本来あるべき形で機能したケーススタディ と言えます。
Mehmet氏が実証データを共有してくれたことで、その日の終わりまでにレポートは適切な担当者に共有され、当社のセキュリティエンジニアがNeonが搭載している正確なPostGISバージョンに対して検証を行いました。通常のテナントロールから脆弱なコードパスに到達可能であることを確認し、それに応じた対応をとりました。
初期の段階で、私たちは明確な決断を下しました。これはすべてのプラットフォームチームが最終的に直面する問いであるため、ここで明文化しておく価値があると考えています。それは、提供するオープンソースコンポーネントのバグは、依然として自社の問題であるということです。根本原因はアップストリームのPostGISにありましたが、そのリスクへの露出は当社の責任でした。私たちはその拡張機能をデフォルトでテナントに提供していたため、その影響を引き受ける必要がありました。「サードパーティ製品」として片付けるのではなく、レポートを受け入れ、対応を主導し、報告してくれた研究者に報奨金を支払いました。
また、お客様がリスクにさらされている間、アップストリームのリリーススケジュールをただ待つわけにはいきませんでした。当社の拡張機能ビルドシステムは、アップストリーム of Postgres拡張機能をコンパイルしてパッケージ化する前に、修正のバックポートや独自のビルドにおけるリスクのあるコードパスの無効化など、任意のパッチセットを適用できるように意図して設計されています。このパッチセットはアップストリームのソースではなくダウンストリームに存在するため、アップストリームのリリース時期に依存せずに行動できます。そのため、迅速にお客様を保護するための措置を講じると同時に、エコシステム全体を適切に修正するための作業を並行して進めることができました。
恒久的な修正プログラムの構築には、数回の反復作業が必要でした。最初の試みではすべてのケースをカバーできなかったため、不完全なものをリリースするよりも、もう1週間かけて適切に仕上げることを選択しました。強化された修正プログラムがデプロイされ、NeonおよびLakebaseのテナントは保護されました。お客様自身で対応を行っていただく必要はありません。
ここからが興味深く、また少し幸運だった部分です。
正式な修正はPostGISで行われるべきでした。それは彼らのコードであり、彼らのリリースであり、彼らの判断だからです。Databricksは、地理空間分野の基盤となる部分を主にボランティアとして維持してくださっているPostGISのメンテナーの皆様に感謝いたします。Mehmet氏も明らかに同じように感じており、行動を起こしました。彼は報奨金をPostGISプロジェクトに寄付し、さらに同額を自腹で上乗せして、マネージドPostgres業界全体が依存しているコードを支えるボランティア活動にその報酬を直接還元したのです。私たちの計画はシンプルでした。まずお客様を保護し、その後Mehmet氏と協力してアップストリームで根本原因を修正してもらい、Neonだけでなくaddress_standardizerを実行しているすべての人が恩恵を受けられるようにすることでした。
その後、ある偶然によって事態は少し複雑になりました。ほぼ同時期に、根本的なバグがアップストリームで、CVEの割り当てや大々的な発表もなく、小さなメモリリークの修正としてパッチが適用されたのです。
結局のところ、アップストリームの修正ではすべてのケースをカバーできていないことが判明しました。Mehmet氏は不十分な箇所を正確に検証し、残りの部分をアップストリームに再提出することで、コミュニティ全体のギャップを埋めました。この一連の脆弱性に対してCVEは割り当てられませんでした。これは、重要なメモリ安全性に関する修正が、リリースノートで「軽微な」クリーンアップとして簡単に見過ごされてしまう可能性があるという、ちょっとした教訓を示しています。
私たちが重視する教訓は、研究者が根本原因に対して正しい対処を行い、アップストリームが完全な修正を受け取り、その一連のプロセスの間、当社の顧客はすでに保護されていたということです。
オープンソースコンポーネント上に構築されたマネージドサービス（マネージドデータベースなど、あらゆるマネージドサービス）を運用している場合、この話における不都合な真実とは、自社のアタックサーフェス（攻撃対象領域）に、自社が書いていないコードや、その作成者が想定していなかった脅威モデルが含まれていることです。小規模で人気があり、あまり更新されていない拡張機能は、まさに提供しやすく、忘れ去られやすいものの典型です。
当社で効果があり、皆様にとっても役立つかもしれないいくつかの取り組みをご紹介します。
セキュリティ研究者の方からのご連絡を心よりお待ちしております。特に、Mehmet氏のように、プラットフォームに対する実質的かつ測定可能な影響を示していただける場合は大歓迎です。hackerone.com/databricks からご報告ください。
詳細に文書化された誠意ある報告を行い、アップストリームの根本原因に対して正しい対処をしてくださったMehmet Ince氏に感謝いたします。また、地理空間情報の世界を支える重要なオープンソース活動を行っているPostGISのメンテナーの皆様にも感謝いたします。そして、報告を迅速かつ冷静に受け止め、修正プログラムのデプロイへと繋げてくださったNeonおよびLakebaseのエンジニアの皆様に感謝いたします。
プラットフォームの安全性を高めるために協力してくださっているすべての研究者の皆様の取り組みに、心から感謝いたします。HackerOneでお会いしましょう。
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。