Apache Traffic Server の脆弱性の発見と報告

はじめに

こんにちは。システム統括本部 プラットフォーム開発本部 エンジニアの小柴（@masaori335）です。Yahoo! JAPAN は多くの Open Source Software（以下 OSS）に支えられています。そのなかの 1 つに Apache Traffic Server（以下 ATS）があります。ATS は過去にこの TechBlog でも紹介したこともある非常に高性能なキャッシュ/プロキシサーバーです。（*1）私の所属するチームでは日頃 ATS コミュニティへバグの報告やパッチの提供などを行っています。この記事ではその活動のなかから『ある脆弱性を発見した顛末』を紹介します。

CVE-2014-3525

脆弱性の内容

ATS のヘルスチェックリクエストと同じパスを指定することで、ATS が動作しているサーバー上の任意のポートに ATS 経由でアクセスできてしまう。

対策

ats-5.0 系であれば 5.0.1 以上に、ats-4.2 系であれば 4.2.1.1 以上にアップグレードしてください。ats-3.x 系はサポートされていませんので、4.2 系もしくは 5.x 系に移行してください。

詳細

社内チャットで 匿名希望の社員 M さん から『ATS 5.0 系を使用すると ATS が再起動を繰り返す』という報告をもらい、調査を始めました。

ATS のプロセスとヘルスチェックの説明を簡単にします。ATS は次の 3 つのプロセスから構成されています。

• traffic_server : キャッシュ/プロキシサーバーとして実際に機能するプロセス
• traffic_manager : ATS の起動/停止や設定の変更を行うプロセス
• traffic_cop : traffic_server と traffic_manager を監視するプロセス

traffic_cop プロセスは traffic_server プロセスと traffic_manager プロセスに対して定期的にヘルスチェック用の HTTP リクエストを送り、状態を監視します。このレスポンスが返ってこなかったり、内容がおかしいようであれば traffic_cop プロセスが『異常がある』と判断して traffic_server プロセスと traffic_manager プロセスを再起動します。

匿名希望の社員 M さん から報告のあったバグを追って行くと、このヘルスチェック用の HTTP リクエストのレスポンスが 400 になってしまっているため、traffic_cop プロセスが traffic_server プロセスを再起動させていたことがわかりました。

気になってもう少し詳しくみてみると、このヘルスチェック用の HTTP リクエストは次のリクエストを traffic_server プロセスのバックドアポート（デフォルトでは 8084）に対して送っていました。

GET http://127.0.0.1:8083/synthetic.txt HTTP/1.0

traffic_server プロセスはこのリクエストを受け取ると、traffic_manager にこのリクエストをプロキシして traffic_manager がレスポンスを返します。つまり traffic_server は受け取ったリクエストが『ヘルスチェック用の HTTP リクエストだ』と判断すると『設定に関わらず』フォワードプロキシとして動作します。

通常 ATS をリバースプロキシとして設定した場合、フォワードプロキシとして動作しないようにします。フォワードプロキシとして公開してしまった場合、踏み台として悪用されてしまう危険性があるためです。

ここまでわかった時に『ヘルスチェック用のリクエストのチェックが甘かったりするとやだよねー。まさかそんなことはないよねー。』とチームで雑談しながら、ポートを変えてアクセスしてみると通ってしまいました。

原因は『ヘルスチェック用の HTTP リクエストだ』と判断する条件が『フォワード先のホストが local_host_ip_str（デフォルトでは "127.0.0.1"）』かつ『パスが "synthetic.txt" である』になっていたためです。つまりメソッドやスキーマ、ポートのチェックがされていませんでした。

というわけで『パスが "synthetic.txt" であれば任意のポートにアクセスできてしまう』ということに気づきました。ポートをチェックするようにした簡単なパッチを書いて、Apache Software Foundation のセキュリティチームと ATS の Project Management Committee に報告しました。

その後の経緯

• 2014/07/09 : 脆弱性発見
• 2014/07/10 : Apache Software Foundationに報告
• 2014/07/24 : 脆弱性が修正されたコードがコミットされる
• 同日 : ATS コミュニティからアナウンスされる [ANNOUNCE] Apache Traffic Server releases for security incident CVE-2014-3525
• 2014/08/22 : NVD に登録される Vulnerability Summary for CVE-2014-3525
• 2014/08/26 : CVE-2014-3525 の詳細が公開される

振り返り

今回は自分たちが脆弱性を発見したので、早期に対応することができました。もしも他の方がこの脆弱性を発見して、自分たちが ATS コミュニティとまったく関わっていない状況を仮定すると、この脆弱性を知ったのは最短でも NVD に登録された 2014/08/22 もしくは CVE の詳細が出た 2014/08/26 だと考えられます。場合によっては CVE を見逃してしまって、公開されている脆弱性に気づかないまま使い続けてしまったかもしれません。OSS コミュニティに関わることのメリット/デメリットはさまざまありますが、メリットの1つに情報をはやく手に入るということも挙げられるのはではないでしょうか。

まとめ

素直な感想としては、Apache Software Foundation のトップレベルプロジェクトで活発に開発が行われているような OSS でもこのような脆弱性が長年発見されていなかったことにとても驚きました。よく耳にする話ですが『OSS はそれを単に使うだけではなく、コードを追って中身を知って、貢献していくことが大事』ということを実感しました。これからも OSS コミュニティの恩恵を受けるだけではなく、バグの報告やパッチの提供などを行っていきます。

Appendix

• *1 Yahoo! JAPAN における HTTP/2 への取り組み
• Apache Traffic Server
• [ANNOUNCE] Apache Traffic Server releases for security incident CVE-2014-3525
• CVE-2014-3525
• ATS のプロセスについてのドキュメント（和訳）: Traffic Server Processes
• 脆弱性が修正されたコミット : limit access to synthetic healthcheck