Fastly の脆弱性修正プロセスをご紹介
私たちは、Fastly のプラットフォームを使用して優れたものを構築したり、素晴らしいサービスを設計し、時にはミスも指摘してくれるエンジニアの皆さんを常に尊敬しています。例えば先日、研究者の Emil Lerner 氏は、Fastly の脆弱性公開プログラム (Vulnerability Disclosure Program) に、発見した興味深いバグに関するレポートを提出してくださいました。
今回はこの機会を借りて、脆弱性に対する Fastly の対応プロセスとエンジニアリングチームをご紹介したいと思います。何がうまく機能しているか、なぜうまく機能しているかについて、お互いから学ぶのが一番の近道だと思います。
このブログ記事では、Lerner 氏が発見したバグの内容、Fastly がトリアージ後わずか1週間で完全なパッチを公開したプロセス、そしてこれほど迅速にパッチを公開できた理由についてご説明します。CISA は、修正までの推奨期間を30日間としていますが、Fastly はトリアージ後わずか7日間で修正を完了しました。
詳しい説明に入る前に、この脆弱性がお客様を攻撃するために悪用されたと見なされる証拠や理由はないことにご留意ください。
Fastly の脆弱性修正チーム
Fastly のセキュリティ組織の一部である脆弱性修正チームの目的は、発見された脆弱性を把握し、社内のエンジニアリングチームの修正作業を支援することです。私たちはセキュリティ研究者および社内のエンジニアリングチームと密接に連携し、脆弱性をモニタリングし、修正しています。脆弱性修正チームは、迅速かつ徹底的に修正作業を遂行できるよう、いくつかの分野に特に力を入れています。
まず第一に、脆弱性のトリアージプロセスの改善に絶えず取り組んでいます。Fastly のトリアージプロセスでは、報告された問題を5営業日以内に把握して再現できるよう努めています。これは一般的な「トリアージにかかる時間」の半分です。
次に、脆弱性のトリアージプロセスにおいて、エンジニアリングチームがデバッグ作業を行えるよう、できるだけ多くの情報を提供します。このためには、レポートの内容をいかに効率的に伝えるかが非常に重要です。たとえば、問題を迅速に再現するメソッドを自動化された方法でエンジニアリングチームに伝えることが望ましいです。
最後に、優れたエンジニアの採用に重点的に取り組んでいます (現在も募集中です)。Fastly には、ネットワークプロトコルおよびシステムレベルのプログラミングに関する深い専門知識を有する、非常に有能なチームが存在します。その結果、今回の脆弱性への対応でも見られたように、チームのプロセスとワークフローに従ってレポートを確認し、迅速に対応することができます。
脆弱性
2021年11月23日に報告された脆弱性は、HTTP/1、HTTP/2、HTTP/3 をサポートする、最適化された HTTP サーバーである H2O における HTTP/3 サーバーサイドの実装に関するものです。Fastly は、このオープンソースプロジェクトの主要貢献者です。H2O サーバーが QUIC フレームのセットを特定の順序で受信すると、H2O は初期化されていないメモリを、受信した HTTP/3 のフレームとして処理することが判明しました。
H2O がリバースプロキシとして使用されると、攻撃者はこの脆弱性を悪用して以下の図のようにリバースプロキシによって H2O の内部ステートが攻撃者または第三者がコントロールするバックエンドサーバーに送信されるようにすることができます。攻撃者は H2O サーバーがダンプする情報を正確にコントロールすることはできません。これには他のユーザーのリクエストやそれに対するレスポンス、または過去に解放された H2O のメモリに存在するその他の情報が含まれる可能性があります。
CVE-2021-43848 と呼ばれるこの脆弱性は、Fastly で HTTP3 を有効にしているお客様の、HTTP3 上で動作しているサービスにのみ影響します。前述のように、この脆弱性がお客様を攻撃するために悪用されたと見なされる証拠や理由はありません。
修正プロセス
Fastly の初期トリアージチームがレポートを受け取り、受領を確認した後、脆弱性トリアージチームによって、より緻密なテクニカルレビューが行われました。
同チームがレポートを確認して問題を再現した後、エンジニアは24時間以内に問題を特定し、パッチを作成してテスト環境にデプロイしました。その結果、H2O の HTTP3 受信バッファが lib/http3/common.c の h2o_http3_update_recvbuf を介して更新され、バッファのサイズが新しいサイズより小さい場合、バッファに使用されたメモリが再利用前にクリアされないことが判明しました。
脆弱性トリアージチームは再度テストを実施し、コードの変更によって問題が修正されたことを確認しました。修正の確認後、パッチの公開プロセスを開始および完了しました。以下に全体のタイムラインを示します。
2021年11月23日 : 研究者が問題を報告。
2021年11月24日 : 初期トリアージチームがレポートを受理。
2021年11月29日 : 脆弱性トリアージチームがレポートの調査を完了して問題の再現を確認。
2021年12月1日 : エンジニアリングチームがパッチを作成してテスト環境にデプロイ。脆弱性トリアージチームが再度テストを行い、パッチを検証。脆弱性トリアージチームが報告者の研究者に連絡し、提案したコード変更によって脆弱性が修正されたことが研究者によって確認。
2021年12月8日 : パッチの公開を完了。
最後に
最終的に Fastly はレポートに報奨金を付与し、上記のタイムラインが示すように、ほんの2週間程度でプロセス全体を完了できました。私たちは、チームが問題に迅速に対応できたことを高く評価しています。また、このレポートを送信してくれた Emil Lerner 氏に感謝します。Lerner 氏の投稿はこちらからご覧いただけます。
