2020年9月3日
まれな一連の条件が揃ったために発生したログの誤ったルーティングに関する調査の概要を示す Fastly のセキュリティアドバイザリー (FSecA) については、以下を参照してください。
この FSecA は、この調査の対象範囲と影響を明確に理解し、これまでに実施された対策について説明することを目的にしています。
7月29日の午前0:00 (UTC)、Fastly はあるお客様 (「X」とします) から、別のお客様 (「Y」とします) 向けの1行のログがお客様 X のログシステムに届いたとの通知を受けました。Fastly では速やかに調査を開始し、複雑な一連の条件が発生した場合に、1行のログが誤って正しくないログサービスにルーティングされる可能性があることを特定しました。エラーの根本原因は、2012年4月にパフォーマンスの改善を目的に Fastly が導入したロジックにあることが判明しました。このお客様からのレポート以外に、この問題に関する連絡を Fastly は受けていません。つまり、過去8年間でこの問題が発生する条件が同時に揃ったのは1度のみということになります。
Fastly ではこのインシデントについて詳しく調査し、以下の条件が重なった (以下のすべての条件に該当する) 場合に問題が発生することを確認し ました。
過去8年間でこれらの条件がすべて揃うことが以前にあった場合、Fastly はすでに通知を受けていたと確信しています。Fastly では、いかなるデータ破損の可能性もきわめて深刻に受け止めています (HTTP/2 クライアント接続を行うサービスのルーティングが正しく行われない問題についておよび 他の Fastly サービスへのリクエストボディの開示について。今回のケースのように、誤って記録されたログが1行だけであったとしても、Fastly は根本原因の分析を怠りません。今後同様の問題が発生することを回避するため、保護機能を導入しました。
ログの書き込みの際のメモリ不足 (上記の条件2) に Varnish が対処するためのソリューションをフリート全体にデプロイし、これらの条件が重なった場合にログデータが誤ってルーティングされることがないようにしました。この修正の適用以降は、ログイベントの構築の際にエラーが発生するとプロセスが失敗し、ログが書き込まずに破棄されます。フリート全体への修正のデプロイは、7月31日の午前10:51 (UTC) に段階的に開始され、8月9日の午後2:49 (UTC) に完了しました。
Fastly では、修正デプロイ後の8月13日から9月2日の期間に、このエラーを引き起こす条件に関する大規模な調査を実施し、ログの誤ったルーティングの潜在的な発生率を確認しました。
調査の結果、お客様によるアクションは必要ありません。万が一予期しないログを受信した場合はご連絡ください。この問題に関連するものであるかを調査します。
2020年7月29日のイベント
2020年7月31日のイベント
2020年8月9日のイベント
2020年8月13日から2020年9月2日までのイベント
その他にご質問がある場合は、support@fastly.com より Fastly カスタマーエンジニアリング、または security@fastly.com よりFastly セキュリティチームにお問い合わせください。