> >

背景

QuickTime Player が取り扱うプロトコルに RTSP というのがあります。これは動画や音声などのマルチメディアコンテンツをサーバが提供するときに、クライアントから再生や停止を指示もできる双方向のプロトコルで、色々なマルチメディアプレーヤーで採用されています。

RTSP のメッセージのヘッダ部分は HTTP メッセージのヘッダによく似ていて、同じように Content-Length という情報のボディの長さを指定するフィールドがあります。

内容

この脆弱性は RTSP の応答メッセージの Content-Length ヘッダフィールドに対する起因するデータの境界検査の誤りを付くものです。十分な大きさの(スタックベースの)メモリ領域にデータをコピーせず、そのメモリ領域を超えてデータを書き込ませることができます。

影響

このためリモートからの RTSP を介して攻撃が成功すると QuickTime Player を通して任意のコードが実行できてしまいます。失敗しても QuickTime Player がクラッシュして DoS 状態にさせられてしまいます。

対象

SecurityFocus では QuickTime 7.2 と 7.3 が影響を受け、他のバージョンも同様であろうとしています。この脆弱性の実証コードのコメントでは Windows Vista および XP SP2 の QuickTime 7.2 と 7.3 でチェックされたようです。(そのことが Mac 版の QuickTime に影響しないことを意味しているわけではありません。)

対応

現在のところこの脆弱性に対する修正はありません。

対応としては怪しいところではマルチメディアコンテンツを見ないようにするということくらいでしょうか。

追記

Secunia では Content-Type としています

Secunia でも「Apple QuickTime RTSP Reply "Content-Type" Header Buffer Overflow - Advisories - Secunia」が掲載されました。危険度は五段階中最高の「Extremely critical」としています。

Secunia では Content-Length ではなく Content-Type の値がとても長い RTSP 応答メッセージとしています。Secunia からリンクされている「US-CERT Vulnerability Note VU#659761」でも Content-Type の記述があるので恐らくはそちらの方が的を射ているものと思われます。

US-CERT では対策として RTSP の URL をブロックする方法を挙げています。ファイアーウォールやプロキシサーバのルールでブロックしたり、QickTime やそのブラウザプラグインの設定で RTSP を使用しないようにするというものです。

RTSP が遮断されるとストリーミングサービスが遮断されるのにかなり等しいですが、滅多に出されない「Extremely critical」レベルの危険度なのでパッチが出るまで致し方ないでしょう。

Mac 版への攻撃も確認されたそうです

「The Mac Security Blog » Post Topic » QuickTime Streaming Flaw Threatens Mac and Windows」によれば Mac 版にも同様の脆弱性があり、既にそういう攻撃がたくさん発見されているそうです。

JVN にも掲載されました

JVN にも「JVNVU#659761: Apple QuickTime RTSP の Content-Type ヘッダの処理にスタックバッファオーバーフローの脆弱性」が掲載されました。US-CERT と同様の対応策が書かれていますが、日本語なのでここに書いてあること、リンクされていることを参考にパッチが出るまで対策しておくことをお薦めします。

SecurityFocus も Content-Type の勧告出していました

「Apple QuickTime RTSP Response Header Content-Type Remote Stack Based Buffer Overflow Vulnerability」と SecurityFocus も Content-Type に起因する脆弱性の勧告を出していました。このエントリで取り上げた勧告より少し前に出ています。どうやら他では一つにしていたものを SecurityFocus では二つの脆弱性と解釈していたようです。