デバイスドライバの脆弱性調査と分析
藤澤一樹 †大久保隆夫 †田中英彦 †† 情報セキュリティ大学院大学
221-0835 神奈川県横浜市神奈川区鶴屋町 2-14-1{mgs061101,dgs063104,tanaka}@iisec.ac.jp
あらまし デバイスドライバは一般に特権で動作するので，セキュリティ上の致命的な問題となることが知られており，近年ではその脆弱性を狙った攻撃が増加している．そこで本稿では，デバイスドライバの脆弱性調査／分析から，デバイスドライバに起因するセキュリティ上の問題点とその原因を明らかにすることによって，既存研究ではこれを防げないことを述べる．さらに現状最も有効な対策として考えられているデバイスドライバの開発／テスト工程における脆弱性検査の限界を指摘し，運用時における保護の必要性を述べる．

Survey and Analysis of Device Driver Vulnerability
Kazuki Fujisawa†

Takao Okubo†

Hidehiko Tanaka††Institute of Information Security
2-14-1 Turuya-cho, Kanagawa-ku Yokohama, Kanagawa, 221-0835 Japan{mgs061101,dgs063104,tanaka}@iisec.ac.jp

Abstract Generally, device drivers run in the privilege mode and it can be the critical problem
for security. So crackers tend to aim the device driver’s vulnerabilities in recent year. In thispaper, we make survey device driver’s vulnerabilities to point out the limitation of existing
methods and argue about our dynamic approach that protect device drivers on running.

はじめには，最小特権のセキュリティ原則に基づいた強制アクセス制御機能を提供することで，攻撃者デバイスドライバはデバイスを制御し，抽象の root 権限奪取を防ぐ SELinux1) があるが，そ化したインタフェースをアプリケーションに提の機能はユーザ空間向けのものであるため，デ供するためのソフトウェアである．近年では，デバイスドライバが動作するカーネル空間では効バイスが高機能化することによってデバイスド果を発揮できないという問題もある．
ライバのコード量が増えたために，セキュリティ
また，近年急速に普及している携帯電話や情上のバグを持つ可能性が潜在的に高まっており， 報家電は Windows Mobile や Symbian OS，組
さらに Windows や Linux ではデバイスドライ
み込み Linux などの汎用 OS を利用する傾向がバが最高特権で動作するので，その問題はより強まっており，これらは個々のデバイス専用の深刻なものとなっている．加えて，Windows でOS に比べて多くのデバイスドライバを含んではカーネルに対する仮想化機能やセキュリティ いる．シンクライアントや VMM（Virtual Ma機能の追加など多様な用途向けにデバイスドラ
chine Monitor または Hypervisor）も同様にもイバを用いるので影響範囲も大きい．Linux でデバイスドライバは必要である．

1さらに，様々なセキュリティベンダーからサードパーティ製のデバイスドライバを狙った攻撃が今後，増加することが指摘されるようになり，デバイスドライバに関するセキュリティ上の問題が増えていくと考えられる．しかしながら，デバイスドライバに関する研究はこれら問題への対策よりも可用性を高める研究が主流である．
そこで本稿では，デバイスドライバの脆弱性調査／分析から，デバイスドライバに起因するセキュリティ上の問題点とその原因を明らかにすることによって，既存研究ではこれを防げないことを述べる．さらに現状最も有効な対策として考えられているデバイスドライバの開発／テスト工程における脆弱性検査の限界を指摘し，運用時における保護の必要性を述べる．

2

関連研究

本章では，デバイスドライバのバグを極小化する取り組み，特権で動作するデバイスドライバを極小化する取り組み，特権から完全にデバイスドライバを排除する取り組み，デバイスドライバを隔離する取り組みについて述べる．

dom 0
DD

dom U

BED・・・

dom U

FED
Xenbus

XenHardware

図 1: Xen アーキテクチャ

2.2

特権動作のデバイスドライバの極小化

Windows や Linux は特権でデバイスドライバを動作させていることについて既に述べたが，通常特権モードで動作するデバイスドライバを特権モード動作と非特権モード動作に分け，特権モード動作するデバイスドライバを少なくすることでデバイスドライバが原因で起きる問題の影響を小さくする手法である．この手法は Microsoft の Windows Vista でカーネルモードドライバとユーザモードドライバ 3) として実装されている．
2.3

特権動作からの排除

一般的に MINIX 3 をはじめとする Microkernel や Exokernel6) においてはユーザ空間でデバデバイスドライバそのものに存在するバグをイスドライバを動作させることができるため，出来る限り排除することでシステムへの影響を特権からデバイスドライバを排除が可能である．
小さくする手法である．例として，Microsoft がまた，VMM 自体にデバイスドライバを持た提供しているデバイスドライバの検査ツールとせないことでデバイスドライバの脆弱性によるデバイスドライバ署名 2) を挙げる．デバイスド影響を排除する手法がある．この手法はケンブライバの検査ツールは，開発者に対して提供しリッジ大学で開発された VMM である Xen に実ている Windows DriverKit（WDK）4) という装されている．この Xen7) は，既に研究されてデバイスドライバ開発キットのテストツールでいた Microkernel，Exokernel らを踏まえておりある Static Driver Veriﬁer（SDV)5) のことで，
図 1 に示すようなアーキテクチャをとっている．
主に関数のテストやアクセス制御の方法と関連
Xen 自体はデバイスドライバを持たなく，管理する同期化などの項目を検査できる．もう一方ドメイン（dom 0）のデバイスドライバを利用のデバイスドライバ署名は，Microsoft がデバする．dom 0 は Xen を管理する特権ドメイン
イスドライバを検証し，問題がなければ署名をであり，非特権ドメイン（dom U）とは区別さ行うものである．
れる．dom U からデバイスへのアクセス要求がまた，Windows や Linux 等 OSS（Open Sourceあった場合，必ず Frontend Driver（FED）がSoftware）においても使えるソースコードの脆
Xenbus を通って Backend Driver（BED）にア
弱性検査等が行える Source Code Auditing Tool
クセスし，dom 0 のデバイスドライバがデバイ（以降 SCAT）が存在する．
スへアクセスする構造をとっている．

2.1

バグの極小化2.4

隔離Microkernel アプローチであれば，それぞれのサービスごとに隔離することが可能であるため，デバイスドライバが故障しても OS がクラッシュすることはない．しかし，モノリシックカーネルであるとデバイスドライバの故障が OS をクラッシュさせる．そこで，カーネル拡張機能を保護する仕組みとして研究されていた Nooks8)をデバイスドライバに最適化した研究 9) によってモノリシックカーネルであっても隔離と仮想的なデバイスドライバを用いることでデバイスドライバの故障から OS を保護できる．

3

調査と分析

この章では，デバイスドライバの脆弱性に起因する問題と，脆弱性の原因を明らかにするために，調査，分析を行った．デバイスドライバにおける脆弱性の調査概要及び，調査結果，分析結果について述べる．

3.1

調査概要

らセキュリティを考慮して作られておらず，問題を起こしたもの．実装ミスは，セキュリティに関する項目以外は全て実装済みのもの．実装
項目の欠如についてはある部分の処理に対して何も書かれていないものと定義する．
次に最も大きな分類を小さく分類していくにあたってデータの取り扱い，権限の取り扱い，入力値の取り扱い，バッファの取り扱い等にした．また，矢印（→）は，分類を受けて何が原因となったかを指名している．表 1 に調査結果を示す．
また，この調査では Windows Vista におけるデバイスドライバの脆弱性は存在しなかった．
その理由として，発売時からの時間が短いこと，SCAT，SDV，署名，ユーザモードデバイスドライバとマイクロカーネルアプローチがとられていることが考えられるが，Windows XP やWindows 2000 におけるデバイスドライバの脆弱性はセキュリティ対策ソフトウェアが用いるデバイスドライバの場合が多く，そうなれば Windows Vista でも起きるため時間の問題だと考えられる．

分析するにあたっては 2007 年 8 月 13 日の3.3 分析結果
SecurityFoucus10) の脆弱性情報を利用した．有
名な脆弱性しか存在しないがデバイスドライバ根本的な原因として，もっとも高い割合を示の脆弱性に起因する問題を整理し，脆弱性の原すのは図 2 に示すように圧倒的に実装ミスが多因を明らかにするためには十分であると考えた． い．その中でも，図 3 から，「入力値の取り扱い」，デバイスドライバに関する脆弱性は 48 件該当 「バッファ不足」，「権限の取り扱い」で 70%を占したが，複数の脆弱性を一つの項目に書いていめる．さらに「メモリの取り扱い」，「予期しなるものは，複数の脆弱性を，それぞれ一つとしい動作」を含めると 88%という割合が多くのプてカウントし，デバイスドライバというよりも， ログラミングで共通する実装ミスにあたり，上ライブラリや OS そのものの問題である場合は位 3 件である「入力値の取り扱い」，「バッファ不除外した．また，今回の調査はデバイスドライ足」，「権限の取り扱い」という脆弱性によってバの脆弱性に起因する問題と，脆弱性の原因を起きる問題は，権限昇格／任意のコードが実行明らかにするために行うため OS やアプリケー可能／クラッシュ／ DoS という非常にクリティション，デバイスの種類に関しては言及しない． カルな問題が引き起こされることがわかる．

3.2

調査結果

SecurityFocus のサイトからデバイスドライバ以外のものを除外した結果，該当項目は 45件になった．
調査結果における最も大きな分類は，設計ミス，実装ミス，実装項目の欠如，詳細不明の 4通りにした．設計ミスについては，設計段階か一般にアプリケーションでは，Buﬀer Overﬂow の脆弱性が多数を占めるが，デバイスドライバでは，入力値の取り扱いや権限の取り扱いミスが存在する．

表 1: デバイスドライバにおける脆弱性のまとめ
分類

原因結果

設計ミス

データの取り扱い → Information Disclosure
データの取り扱い
特定の条件
データの取り扱い → 最小データの処理
その他→ Flag の未実装
入力値の取り扱い

データリーク
セキュリティソフトの回避可能
システムクラッシュ
データリーク
不明
権限昇格／任意のコードが実行可能／
クラッシュ／ DoS ／データリーク
権限昇格／任意のコードが実行可能／クラッシュ
権限昇格／任意のコードが実行可能／クラッシュ
権限昇格／任意のコード実行可能／ DoS
クラッシュ／権限昇格
DoSデータリーク
クラッシュ／ DoS
権限昇格／ Buﬀer Overﬂow／ DoS ／クラッシュ
データリークDoSDoS ／権限昇格
X のクラッシュ
クラッシュ
クラッシュ

実装項目の欠如
実装ミス→ Integer Overﬂow
バッファ不足 → Buﬀer Overﬂow
権限の取り扱い
メモリの取り扱い→ メモリリーク→ Memory Disclosure
予期しない動作
Secure Code Audit

詳細不明

データの取り扱い → データの保存方法
バグ—————— → DRM の実装——— → Information Disclosure
データの取り扱い → 特定の条件

詳細不明
9%

設計ミス
7%

実装項目の欠如
7%

脆弱な関数
3%
Source CodeAudit3%
予期しない動作
6%

データの保存方法
3%
バグ
3%
入力値の取り扱い28%

メモリの取り扱い
12%

実装ミス
77%

バッファ不足21%

権限の取り扱い21%

図 2: 根本的な原因の割合
図 3: 実装ミスにおける原因の割合

4

不完全な保護方法

2 章において，現在，行われている取り組みを述べた．3 章において，デバイスドライバの脆弱性に起因する問題と脆弱性の原因を明らかにし，デバイスドライバの脆弱性が如何に脅威であるかを述べた．この章では，現在，行われている方法では根本的な解決にはならないことを示す．
脆弱性検査ツールは，有効であると考えられるが SDV によって検査できるのは Windows ド
ライバモデル (WDM) 使用ルール違反が無いかどうかを検査しているからであり，WDM のよ
うな，デバイスドライバに対しての決まりが存在していない場合は不可能であり，WDM 自体にセキュリティ上の問題があった場合などは修正も困難にする．また，デバイスドライバから完全に脆弱性を排除することは非常に困難である．デバイスドライバ署名も Windows DriverFoundation(WDF) が存在していることと，OSが Microsoft のみで開発されているからであり，OSS で署名を行うとすると誰が署名するのかが難しく困難である．また，SCAT である OSS の題点について考察する．
RATS - Rough Auditing Tool for Security11)
ウォータフォールモデルのソフトウェア開発を利用し，実装ミスの上位 3 件から数件をチェッであれば設計→実装→テスト→運用という流れクしたが，「バッファ不足」に起きる既知の Buﬀerになる．近年では，それぞれの工程において脆Overﬂow は検知できたものと未検知のもの，「権弱性検査が必要だと言われるが，全てに対して限の取り扱い」については検知不可，「入力値の脆弱性検査をすると非常にコストがかかるため取り扱い」の Integer Overﬂow については検知運用時に IDS や Firewall，sandbox などで後付というように，SCAT は，ウィルス対策ソフト的にセキュリティ機能を付加する場合が多い．と同様にシグネチャ方式であるため既知のもの
デバイスドライバに関しては特に運用時に保しか検知できないだけでなく，既知，未知を含護する仕組みはなく，対策として実装時とテスめて全て検出できるわけではない．また，次のト時における脆弱性検査が重要になる．この実ようにプログラムのコンテキストに依存するた装時とテスト時に防ぐことが可能な脆弱性はめ，前提が必要なものや，トリガーとなる関数「実装項目の欠如」と「実装ミス」であり，全がユーザ定義のものなどは検出するのが難しい．
体の 84%以上を占める．そのため実装時は，原
特にデバイスドライバは，そのデバイス固有の因として述べた「入力値の取り扱い」，「バッコードが存在するため一般的な監査では完全にファ不足」，「Source Code Audit」，「脆弱な関脆弱性を取り除くことは不可能である．
数」で 55%の問題を防ぐことができる．補助的
既に実装されているカーネルモードドライバに SCAT を用いることで，危険な関数の仕様やとユーザモードドライバは，特権で動作してい既知の脆弱性については，ある程度検知するこるデバイスドライバがあるため根本的な解決にとができるため人間が目だけで検査するよりもならない．
脆弱性を無くす効率を挙げることができる．次Microkernel を採用している Windows 2000の段階であるテストでは，「予期せぬ動作」を行や XP，Vista であっても特権でデバイスドラわないか，「メモリの取り扱い」によって別の空イバを動作させているため根本的な解決にはな間への上書きやメモリリークを起こさないか，らず，Exokernel アーキテクチャを持つ OS は「データの保存方」に問題一般的に使われていない．また，Xen のように 「権限の取り扱い」，VMM にデバイスドライバを持たせない方法は， はないかという点でテストすることで 42%を防VMM を安全にする方式である．しかしながら， ぐことができる．このように開発工程とテスト工程における脆弱性検査において理想的にいけ
Xen においては Xen を管理できる dom 0 のデバ
ば実装ミスの 97%，全体で 81%が防ぐことがでイスドライバを用いているため，デバイスドラきる．
イバの脆弱性を突かれて，dom 0 をリモートコ
しかしながら，既に述べた通り，SCAT は全ントロールできるようになると，Xen のリモーてのソースコードにおける問題を全て検知できトコントロールが可能となる．Nooks や，そのず，あくまでも最後は人が見て判断する必要が後の研究のようにデバイスドライバを隔離し保ある．場合によっては脆弱でないケースを脆弱護する仕組みは非常に有効であると考えられるであると通知することもあるため知識のない者が，これらの研究はデバイスドライバが故障しが使用して脆弱性を発見することは困難である．
た場合に OS をクラッシュさせないために開発されたものであり脆弱性の保護には使えない． また，テスト時においても全てのテスト項目を網羅することは不可能である．そのため，現状5 考察の対策として行える開発，テストの脆弱性検査だけでは限界があるという問題がある．
3 章と 4 章においてデバイスドライバの脆弱そこで運用時に保護する仕組みが必要となる．
性に起因する問題と脆弱性の原因を明らかにし，この運用時に保護する仕組みはデバイスドライ現状の保護方法では防げないことを述べた．そバが動作中に脆弱性を突かれた場合でも問題をこで本章では現状における対策を述べ，その問起こさないようにする方法である．例えば，各デバイスドライバを sandbox の中で動作させるなどが考えられるし，デバイスドライバに SecureOS と同様のアプローチを取り入れることによって，脆弱性を持っていても問題を起こさず動作させる研究 12) もある．このように，デバイスドライバであっても運用時に保護する仕組みがなければデバイスドライバの脆弱性からシステムを保護することはできない．

6

まとめと今後の課題

本稿では，デバイスドライバの脆弱性の危険性を指摘し，調査，分析を経て脆弱性に起因するセキュリティ上の問題と，脆弱性の原因を明らかにした．そして，現在の保護方法では防げないこと指摘し，対策として実装時，テスト時の脆弱性検査が重要であることを述べた．さらに，問題点として，それらの限界を指摘し，運用時に保護する仕組みの必要性を述べた．
今後の課題としては，運用時にデバイスドライバを動的に保護できることを示していきたい．

参考文献
1) SELinux
Stephen D. Smalley, “NSA SecurityEnhanced Linux”, Ottawa Linux Symposium BOF 2006.
2) Microsoft, ロゴ及び WHQL テスト
http://www.microsoft.com/japan/whdc/GetStart/default.mspx
3) Windows Driver Foundation（WDF）
http://www.microsoft.com/japan/whdc/driver/wdf/default.mspx
4) Windows Driver Kit
http://www.microsoft.com/japan/whdc/devtools/wdk/default.mspx
5) Static Driver Veriﬁer
http://www.microsoft.com/japan/whdc/devtools/tools/sdv.mspx

6) MIT Exokernel Operating System
http://pdos.csail.mit.edu/exo.html
7) Keir Fraser, Steven Hand, Rolf Neugebauer, Ian Pratt, Andrew Warﬁeld, Mark
Williamson, “Safe Hardware Access with
the Xen Virtual Machine Monitor”, OASIS ASPLOS 2004 workshop.
8) Michael M. Swift, Brian N. Bershad, andHenry M. Levy, “Improving the Reliability of Commodity Operating Systems”,
ACM Transactions on Computer Systems, 22(4), Nov. 2004.
9) Michael M. Swift, Muthukaruppan Annamalai, Brian N. Bershad, Henry M. Levy,“Recovering Device Drivers”, Proceedings of the 6th ACM/USENIX Symposium on Operating Systems Design andImplementation, San Francisco, CA, Dec.
2004.
10) SecurityFocus
http://www.securityfocus.com/
11) RATS - Rough Auditing Tool for Security
http://www.fortifysoftware.com/
security-resources/rats.jsp12) 藤澤 一樹, 橋本 正樹, 宮本 久仁男, 金 美羅, 辻 秀典, 田中 英彦, “仮想マシンモニタにおけるデバイスドライバ安全性向上に関する提案”, FIT2007 第 6 回情報科学技術フォーラム Sep. 2007.