Ms Word のバッファオーバーフローで任意のコードの実行?

Ms Word のバッファオーバーフロー

2004年10月に危険度の高い、Ms Word のバッファオーバーフロー脆弱性が話題になりました。バッファオーバーフローにより Word がクラッシュしてしまうこと、手法は未発見ですが可能性として悪意ある任意のコードの実行がありうるというものでした。

※念の為にMicrosoft社のupdateを探しましたが現時点ではパッチは無いようです。

追記:4/13のWindowsUpdateにてMS05-023としてパッチが出ています。

バッファオーバーフローを発見したHexView氏とは別にAlex Li氏により第二の報告があったもようです。ことによるとAlex Li氏がコードの実行方法を発見しているのかもしれません。

任意のコードの実行はありうるのか?

コードの実行を行われると大変に危険なわけですが2005年10月の段階ではその手法は未発見とされています。むやみに心配する必要はないのですけれど……しかしですね。

Secunia - Secunia Advisoriesのページの最下段にある「Top 5 Most Read Secunia Security Advisories (Last 24 hours):」(最近24時間で最も読まれた5個のアドバイザリー)を見たところ、Secunia - Advisories - Microsoft Word Document Parsing Buffer Overflow Vulnerabilityが、なんと第4位にランクインしています。まさしくWordのバッファオーバーフローの件です。やや古めのアドバイザリーなのに、なぜこの時期に急浮上してきたのでしょう?4/12追記:ランク外に落ちています。あまり心配は要らないと考えたいです。以下与太ばなしということで。(汗)

さらに4/12追記:以下の記事は完全に与太であることが判明しました。詳しくは4/12の本日記で書きます。やられた〜っ!!!Access関連の新脆弱性が発見されていてWordの脆弱性の発見者と同じ人が発見していたのでした。

セキュリティ系のメーリングリストでは特に関連あるものは見ませんし、ウイルス関連でも特には無いようです。しかし一抹の不安がよぎるわけです。どこかでバッファオーバーフローを衝いてリモートからの悪意あるコード実行に成功したとのレポートがあがっているのではないか、そしてそのレポートからsecuniaのアドバイザリーがリンクで参照されているのではないかと、そのせいでアドバイザリーが読まれる回数が急浮上してきたのではないかと、ちょっとした不安です。なにせ英語圏でないところでは何が起きているか実際にはわかりませんことですし。

まぁ心配しすぎといえばそうなのですけれど。しばらく慎重に行動したいところです。しかしですねバッファオーバーフローの修正って簡単なのではないかと素人ながら想像するのですけれどねぇ…境界侵犯の原因なんて類型化しているでしょうし、バグに気がつきさえすれば修正点はすぐにわかるだろうし。いろいろな仕様の不整合の軋轢で修正してしまうとどこに影響が出るかわからない?というしろものではないはずなんですよねぇ。

慎重に行動する

Internet Explorerでセキュリティゾーンのレベル設定を「高」にする、最低限「Activeスクリプト」「ActiveX」「ファイルダウンロード」をオフにする、こんなところでしょうか。

追記:4/13のWindowsUpdateにてMS05-023としてパッチが出ています。

Outlook/OWAにアドレス詐称の脆弱性

iDEFENSEによる詳細な情報

社会工学的なトリックで差出人を詐称して信用度を高めるということですか。

対策としてはメールのヘッダーを見ることにつきるようですが…多くの人は出来ないよね?根本的にはメールで釣られない心構えでしょうね。やたら信用しないこと。

追記

日本語の記事が出ました。

以下、OutlookにFrom欄を偽装できる脆弱性〜米iDEFENSEが報告 - INTERNET Watchより引用

企業のSMTPサーバーでは、この脆弱性が悪用されることで、あたかも企業内部のアドレスで送信されたかのような外部アドレスのメールを受信してしまう恐れがある。また、攻撃者にとっても企業内部のアドレスを偽装できるため、外部アドレスへの規制を回避できる。

ちょっと悩ましいですね。意外と深刻かも。

フレームを使っているサイトで自動解凍書庫をダウンロードさせてはいけない

自動解凍書庫

拡張子が.exeの自動解凍書庫は、書庫を解凍する処理を自分自身の中に内蔵しています。それゆえ、適切な解凍ソフトウェアを備えていないPCに何かをセットする際にはとても便利です。ですがその便宜性は充分に考えた上で享受しなければいけません。他人が作成した自動解凍書庫をどうして信用できるのかを充分に考えるべきです。私も過去に自動解凍書庫の解凍を数限りなく行いました。ですがその自動解凍書庫は他ならぬ私自身が圧縮したものです。真に安心して使えるとしたらこのケースだけではないでしょうか?

たとえばLHAの書庫はそのままで配布するほうがよいのではないでしょうか。今時解凍処理ソフトを用意出来ないマシンが果たしてどのくらいあるのでしょうか?自動解凍処理をつけたからといってどのくらい福利につながることでしょうか?また、そもそも本当にそのデータなりプログラムなりは圧縮に適しているのでしょうか?

まず私たちは圧縮せずに原本をそのまま配布できないかどうか考えるべきです。次に書庫のうまみ(複数のファイルを1個にまとめることが可能)を享受したいならば、そのまま配布すべきであり、けして自動解凍書庫のexeファイルを配布すべきではありません。自動解凍が許されるとしたら、自動解凍書庫を自分が作成した場合だけであると思われます。(この文章では圧縮解凍処理を行うフリーウェア自身の配布については考慮の対象からはずしています。)

中から何が出てくるか分からない実行ファイルを安易にダブルクリックで開く習慣が広く蔓延していることと思います。自動解凍書庫が、悪しきその習慣の蔓延のお先棒を担いでいるとしたら責任は重大だと思いますがいかがでしょうか。

フレームを使っているサイトでは危険が最大となる

自動解凍書庫の危険性はフレームを使っているサイトで最大になります。

一部のメジャーなブラウザでは、Multiple Browsers Frame Injection Vulnerabilityという欠陥をいまだに抱えたままです。secuniaが提供しているTESTページ脆弱性を抱えているかどうかを判定出来ることでしょう。日本語の解説記事としては以下のものがわかりやすいでしょう。なお、既に脆弱性を克服したブラウザももちろんあります。

この脆弱性の要点は上記ニュースにもあるように細工を施した悪意のあるページにアクセスした場合のみ,「有名企業のコンテンツ+悪意のあるコンテンツ」が同じ画面上に表示されるのである。ということになります。なお、先に触れたscuniaのTESTページでは罠にかかる為には2個のリンクを踏むという、言わば手動でわざとひっかかる必要がありますが、実はこれはsecuniaも言う通り完全に自動化が可能ですので安心は出来ません。

悪意あるコンテンツは、有名企業のコンテンツと良く似ているがしかし、悪意を密かに忍ばせたニセものとなるでしょう。そしてもしもそのニセものページが拡張子.exeの悪意ある実行ファイルのダウンロードを促していたとしたらどうでしょう?名目としては(安全な?)「自動解凍書庫」です。利用者が容易に騙されてしまう可能性が出てきます。

ここまで見てきたように、自動解凍書庫の危険性はフレームを使っているサイトで最大になることがわかります。

悪意あるフレーム内盗用に弱いサイトのモデルケース

フレームを使っているサイトで自動解凍書庫のダウンロードを促している実在のモデルケースがあります。これまで述べてきた危険性が最大になることがすぐにわかります。なにしろ、元々自動解凍書庫をフレーム内でダウンロードさせていますので、ダウンロードする実行ファイルのみを差し替えたニセものを作ることなど極めて容易です。たぶん小学生でも出来ます。ニセダウンロードファイルを解凍するとスタートアップにそれなりに…レジストリ書き換えてスパイウェアを忍ばせることも。それでは実在のモデルケースを。

上のページではフレーム構成になっています。スクロールできるので一番下までもっていって送信ボタンを押します。すると、フレーム内側のページが切り替わります。ここが目的地です。ダウンロード開始のボタンがありますがこれをクリックすると自動解凍書庫をダウンロード出来ます。

ダウンロードされる自動解凍書庫のサイズは 1.55 MBです。一方、解凍して出てくるPDFファイルのサイズは 1.80 MB です。圧縮率はごくわずかですし、そもそも一つのファイルを圧縮しているだけですので書庫としてのうまみも使っていません。PDFファイルの圧縮率が悪いことは有名な話ですのでもともと圧縮するべきものではありません。PDFを生で配布すれば良いところをわざわざ危険な自動解凍書庫の形で配布していることになります。

※余談ですがPDFファイルでの文書公開および配布を公的な機関ないし準公的な機関、大企業等が好んで行っていますが、このことは全くもって首を傾げざるを得ません。検索エンジンにひっかかりにくいので公布・宣伝にはなっていません。本当に皆に知らせたいのであればHTMLファイルとして作成すべきでしょう。アクセシビリティーの観点からもちょっと弱いかと思います。そういえばJISのWEBアクセシビリティー関連の文書類もPDFで配布していますが気が知れません。余談終わり※

閑話休題。上の実例モデルにおいてはたまたま、HTTPSを使っています。これならば大丈夫でしょうか?ここではIEについて考えてみましょう。フレームを使用している場合、アドレスバーに表示されるのは外側のフレームの URL ですし、ステータスバーに表示の錠アイコンもまた、外側のURLに紐ついたものになります。フレーム内側の詐称コンテンツとは無縁です。通常のユーザには確認するすべを持ちません。フレームを使ったサイトでSSLを使おうという発想そのものが基本を全くわかっていないことになります。

ちょっと弁護してさしあげる

なぜ自動解凍書庫をわざわざ使っているのでしょうか。推測するに、隠れた理由があると思われます。問題のPDFをローカルに保存して欲しいのですね、ACCSとしては。で、ダウンロードの便宜をはかったと。通常インストールではIEFirefoxでは生のPDFはブラウザ内で開かれてしまいます。(Operaは異なります)いったんブラウザと一体化したAcrobatReaderがPDFファイルを自動的に開いてしまう、ユーザはそれを保存するメニュー操作を行わざるを得ない、そのことを懸念しているのかと思います。生PDFでは駄目だからexeにすればダウンロードになるだろうと。あくまでもユーザの便宜をはかったものであると、このような弁解は出来るわけです。

ちょっと反対尋問してさしあげる

拡張子exeの実行ファイルをダウンロードする時には例えば多くのシェアを誇るIEにおいてはダウンロード時の警告が出ます。警告ダイアログの表示はXPSP2上ではセキュリティセンターのアイコンが黄色です。これは危ないから出来ればダウンロードは考え直せという意味です。無論、一般的には青いアイコンである場合もあります。それでも一応良く考えろという警告は出ます。黄色いアイコンであればより重大な警告なのです。ユーザを悩ませるようなダウンロード方法を取ることは良くありませんよね?

どうすればよかったか

PDFはAcrobatReaderに開かせれば良いのです。そうすればそれが本物のPDFであることがわかります。AcrobatReaderの機能でデクストップ上に保存させます。この流れでは(不正なPDFではない限り)安全にローカルに保存可能ですし、警告ダイアログも出ません。IEFirefoxではこのやり方で良いでしょう。Operaに関してはいったん開くか保存するか聞いてくるはずなので(既定値では)開いて頂く様に説明をつけておきましょう。このようにして安全に利用者に配布することが可能と思われます。

また、フレームを使ったサイトで公的な活動を行おうとすること自体、是非考え直すべきです。せっかくのSSLはただの飾りとなっていますし、フレームインジェクションの危険性をユーザに負担させていることになるからです。

余談

本当はRFC3778を見ながらThe application/pdf Media Type について考え、あわせて、Content-Disposition をこの場合に使ってよいかどうかも考える予定でしたが、力つきました。MicrosoftはMediaTypeがapplication/pdfであってもContent-Dispositionの指定を行うことで強制ダウンロードさせることが可能であるという立場のようですけれど私見ではどうもうまくないのではないかと思っております。ならばいっそAcrobatReaderプラグインなりActiveXなりにまかせたほうが良かろうという気がいたします。今日の日記の主題はフレームインジェクションと安易な自動解凍書庫の利用に関するものでした。いつか機会があればと思います。

近頃の高校生ときたら

id:Akinoriさんの4月7日の日記を読んでこんな風に思った。

おいおい、最近の高校生ってのは閉じた定義域における連続関数の多項式近似定理とか、「一様連続」の概念とか勉強すんのかよっ!!受験勉強しすぎだろ?

よく読んだら数学オリンピックに出るほどの人だった。神。