gihyo.jpサイトのロゴ

インフラセキュリティの処方箋

第35回2017年6月～EOLなWindowsへの修正ファイル提供と、DLLプリロードの問題

2017-06-29

今月は、すでにEOLを迎えたはずのWindows XPとWindows Server 2003などにも修正ファイルが提供されたWindows脆弱性および、DLLプリロードに関する問題について取り上げます。

EOLになった古いWindows OS向けにも脆弱性修正ファイルが提供される……が、あくまで例外

2017年5月は、脆弱性を突いて感染を拡大するランサムウエア「WannaCry」流行のトリガとなった、MS17-010の修正ファイルがWindows XP向けにも提供されましたが、2017年6月にリリースされた脆弱性修正にも、Windows XP、Windows Vista、Windows Server 2003といったEOLになっているWindows OS向けの修正ファイルが提供されています。

上記のガイダンスで修正が案内されている脆弱性のうち、気になるものがいくつかあります。たとえば、以下のものがその1つになります。

これは「CVE-2017-8543 | Windows Search のリモートでコードが実行される脆弱性」のWindows XP SP3向けの修正になります。

前者はリモートデスクトップ接続経由で悪用可能な任意コード実行を引き起こすことができる脆弱性であり、後者はSMBv1経由でWindows Searchに細工されたデータを入力された場合に、任意コード実行を引き起こすことができる脆弱性です。

前者はリモートデスクトップを有効にしていなければ問題ありませんが、Windows Searchは多くの場合はファイル検索などを高速化するために有効にされており、SMBv1による通信データが外部から送り込まれる可能性のある環境では本脆弱性をトリガ可能です。いずれの脆弱性についても、当初からWindows XP、Windows Server 2003、Windows Vistaといった、サポート終了したOS向けにも修正プログラムが配布されています。なお、Microsoftからの情報では、本脆弱性を用いた攻撃がすでに発生しているとのことで、修正を迅速に適用する必要があります。

2017年5月に紹介したWannaCryで悪用されたMS17-010の脆弱性は、SMBv1経由で任意コード実行を引き起こせる性質のものであり、実際にWannaCry感染拡大に悪用されたことが確認されたこと、そしてWindows XPがまだかなり広範囲に使用されていた事実を踏まえ、Windows XP向けのMS17-010修正プログラムが配布された経緯があることを考えると、今回のCVE-2017-0176やCVE-2017-8543では悪用の事実を確認していること、そして悪用が拡大することを懸念して、サポート終了したOS向けにも修正プログラムを配布していると考えるのが自然です。ただ、EOLになった製品が再びサポート対象になったというわけではありません。前述の「古いプラットフォームのガイダンス」においても、「⁠Microsoftは、今回、古いプラットフォーム用のセキュリティ更新プログラムをリリースしましたが、Microsoftのポリシーが変わったわけではありません。 サポートされているプラットフォームにアップグレードすることをお勧めします。 」という文言が書かれていることからも、古いOSがサポートされ続けるわけではないと考えるのが自然です。

IPAからも、2017年6月の脆弱性についてアナウンスされていますので、必要に応じて確認してみてください。

WindowsアプリケーションによるDLL読み込みやコマンド実行に関する問題への対処

JVNにおいて、2017年6月1日から6月26日までに公開された脆弱性38件のうち、13件がDLL読み込みに関する脆弱性でしたが、このような脆弱性指摘が多いことに関連してか、2017年5月25日に、IPAから本問題に関する参考文書が公開されました。

この問題は、アプリケーションの中で特にDLLを何も指定しているように見えなくても発生するのが厄介です。

たとえば、以下のプログラムをWindowsに付属しているC#コンパイラであるcsc.exeでコンパイルしで生成されるバイナリがどんなDLLをプリロードしようとするかを、Dependency Walkerというプログラムを用いて確認してみましょう。

Dependency Walker
http://www.dependencywalker.com/
using System;

class Program
{
    static void Main()
    {
        Console.WriteLine("Hello World");
    }
}

上記のソースコードを適当なファイル名で保存し、以下のようにコンパイルします。

< c:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe sample.cs
Microsoft(R) Visual C# 2005 Compiler version 8.00.50727.8784
for Microsoft(R) Windows(R) 2005 Framework version 2.0.50727
Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

以下がsample.csから生成されたsample.exeの実行結果です。

<sample.exe
Hello World

そして、sample.exeをDependency Walkerに読み込ませてプリロードされるDLLを確認した結果を図に示します。

図　Dependency Walker実行結果
図　Dependency Walker実行結果

これらのDLLが読み込まれるのに加え、DLL検索パスの優先順位は標準ではカレントディレクトリのほうが高いことから、悪意あるDLLがこれらのファイルと同じ名前で実行ファイルと同じところに置かれた場合に、悪意あるDLLの内容（のうち、DLLの初期化ルーチンなど、プログラムの内容とは関係なく実行される部分）を実行します。

このような問題への対処は、冒頭に紹介したURLに示しておりますが、基本は「実行しようとするアプリケーションがおかれているディレクトリ」に、不審なDLLがすでに置かれていないことを確認することで対応可能です。

これは、アプリケーション配布形式にも依存することがありますが、自分だけ使うようなものでない限りは、アプリケーションを格納するディレクトリを作成の上で、必要最小限のファイルのみをそこにコピーするなり、インストーラによるインストールを行うようにして、実行ファイルと同じディレクトリに不審なDLLがおかれていない状態を作り出すようにするようにしましょう。

おすすめ記事

記事・ニュース一覧