[研究室用] 2038年問題研究の現状報告

Transcript

1. 2024/10/14 全体ゼミ発表 立命館大学 情報理工学研究科 サイバーセキュリティ研究室 星名 藍乃介 2038年問題の原因となりうる ソースコードの⾃動検出⼿法の提案と実装
2. 技術的負債と時刻表現 • サマータイム問題 • GPSロールオーバー問題 • うるう年やうるう秒の考慮不足 ...など 4 ٕज़తෛ࠴ͱ͸ɺ࣮૷౰࣌ ࠷దղͱߟ͑ΒΕ͍ͯͨ΋ͷ͕࣌ؒܦաͱͱ΋ ʹධՁ͞Εͳ͘ͳΔ͜ͱɻ ෛ࠴͕๲Ε্͕Δͱɺ΍͕ͯγεςϜͷ҆ఆՔಇΛڴ͔͢Α͏ʹͳΔɻ • 2000年問題 • 昭和100年問題 • NTP 2036年問題 • 2038年問題
3. 2038年問題とは 5 1. UNIX time (※) を 32bit 符号付き整数型 で扱う。 2. 2038/1/19 03:14:07 以降の時刻で 整数オーバーフロー する。 3. 整数オーバーフローした値がシステムの各所で参照され、不具合に繋がる。 2038/1/19に時間表現がオーバーフローし、システム障害を引き起こす可能性がある という問題。 2004年、IIJや日本IBM、KDDIなどのシステムで2038年問題に起因する不具合が発生した。 「西暦2038年問題」でトラブル相次ぐ | 日経クロステック（xTECH） https://xtech.nikkei.com/it/members/NC/ITARTICLE/20040325/1/ 発生原理 事例 ※ UNIX time とは 1970/1/1 00:00:00からの経過秒で 時刻を表現する形式
4. ೥໰୊͸ڴҖʹͳΓ͏Δ͔ʁ 6
5. 2000年問題では被害が⼩さかったので、2038年問題も問題ない？ 2000年問題の対応費用は 4552億円※ もかかったが、 脅威ではなかったと言えるか？ 2000年問題の被害が小さかった要因 社会問題として広く認知された アプリケーションのみの影響 7 ※日本銀行「コンピューター2000年問題に関するわが金融界の対応状況」（1999年）より ↪ では、2038年問題はどうか？ 対応するべきという経営判断が行われた 西暦の下二桁が繰り上がるというわかりやすさ それより深いレイヤにも影響する問題だったら 修正難易度は飛躍的に上がっていた
6. むしろ、2038年問題は2000年問題よりも深刻という仮説 8 社会的認知度の低さ • 非技術者にとっての理解しづらさ • エンジニアだけでなく、経営者、行政の協力なしでは解決できない 影響範囲はシステムの深層にまで至る • アプリケーションレイヤだけでなく、DB、OS、ファイルシステム、言語処理系など UNIX timeを使用するすべてのソフトウェアが対象 • 代表例：MySQLのTIMESTAMP型、ext2/3 • 提供側が対応すれば完了とはならない →ソフトウェア アップデートされない問題 →ソフトウェア アップデートできない問題（組込みシステムなど）
7. 2038年問題の対策 32bit UNIX time の最大値： 2038年 64bit UNIX time の最大値：西暦 約3000億年
8. 2038年問題対応、型を64bit化するだけで済むか？ 2038年問題対応したつもりでも 実は抜け漏れがあったというシナリオ 10 見落とし 実は UNIX timeが 32bit 符号付き整数型に なる処理が存在していた 2038年問題 発生 整数オーバフローが発生 不具合につながる 2038年問題対応の実施 UNIX time 用変数を 32bit整数型→64bit整数型 に再定義 2038年問題対応の⼤変さ UNIX time がデータフロー内で⼀貫して32bit を超えているか、網羅的に調べる必要がある
9. ͭ·Γɺ೥໰୊͸ ڴҖͰ͋ΔͱਪଌͰ͖Δ 11
10. 2038年問題対応の課題 12 学術的な脅威性評価が必要 ・リスクの詳細を評価することが困難 ・あるシステムに2038年問題の可能性があるかを調べる仕組みがない ・修正にかかるコストや難易度が不明 対応ガイドラインがない ・対応に必要な判断材料が揃っていない ・検出/修正ツールが少ない
11. 2038年問題の研究領域 13 発⾒ リスク分析 修正 ⾏動指針 の提⽰ 問題 領域 研究 領域 ・事例分類 ・バグパターン ・自動検出ツール ・数の多さ ・社会的影響 ・修正難易度 ・修正コスト ・自動修正ツール ・エンジニア向け ・経営者向け ・行政向け ・教育コンテンツ 技術レイヤ ファイルシステム、DB、OS、プログラム言語、フレームワーク、アプリケーション など 製品 組み込み機器（ネットワーク機器、医療機器、交通機器など）、Webサービス など
12. 修⼠研究のスコープ 14 発⾒ リスク分析 修正 ⾏動指針 の提⽰ C言語プログラム およびその周辺システム < C言語の選定理由 > • 歴史的経緯から、C言語プログラムで最も脅威が大きいと考えられるため • UNIX timeは、POSIXという規格の中で規定され、その後広く普及した • POSIX：1980年代に定められたUNIX 系 OS 標準化のための規格 問題 領域 研究 領域 ・事例分類 ・バグパターン ・自動検出ツール ・数の多さ ・社会的影響 ・修正難易度 ・修正コスト ・自動修正ツール ・エンジニア向け ・経営者向け ・行政向け ・教育コンテンツ
13. C⾔語ソースコードから2038年問題の原因となりうるコードを 網羅性⾼く検出する⼿法を提案する。 提案⼿法を⽤いて実際のソースコードを解析して、 2038年問題の脅威性を⽰す。 発見 リスク分析 研究⽬的 15
14. 本研究の貢献 16 • C言語プログラムから 2038年問題可能性 を検出するツールを開発した。 「32bit を超える time_t 型をもつ環境における2038年問題」を検出対象とした。 • 2038年問題のあるソフトウェア一覧表を作成した。 • 874 の C言語OSS に対し、開発した検出ツールを用いて検証を実施した。 全体の 33.6% にあたる 294 のプロジェクトから 3463 の該当表現を発見した。 発見 リスク分析
15. 検出⼿法の提案/実装 発表 • 卒業論文 • IoTセキュリティセンター ポスター発表 • SEC道後 2023 • DICOMO 2023 シンポジウム • ISACA大阪支部 総会 研究講演 • 情報処理学会 論文誌 2024年9月号 研究の流れ 17 2038年問題事例の調査/分類 2038年問題の脅威性の評価 実ソフトウェアへの検証
16. 2038年問題事例の調査/分類 18
17. 検出⼿法 > 検出対象 19 64bit time_t 型であっても 2038年問題起因の整数オーバーフローが起こりうる。 プログラム内部で、タイムスタンプを32bit 符号付き整数型にダウンキャストする際に 整数オーバーフローが生じるパターン。 ・64bit time_t → 32bit int へのキャスト ※ 多くの環境で int は32bit ・64bit time_t → 32bit longへのキャスト ※ 64bit Windowsでは long が32bit プログラム外部で、タイムスタンプを32bit 符号付き整数型で 定義しているパターン。 ・ファイルシステム：ext2/3、XFS (Linux5.10より前) ダウンキャスト 2038年問題のある外部システム
18. 64bit time_t のダウンキャスト パターン 20 ② 変数代入時の暗黙的ダウンキャスト ③ return 時の 暗黙的ダウンキャスト ④ 関数の引数代入時 の 暗黙的ダウンキャスト ① 明示的なダウンキャスト （コンパイラ警告でも検出不可） コードベースに紛れ込んだダウンキャストを、⽬視確認で網羅的に発⾒することは困難
19. 検出⼿法 21 データフロー解析 抽象構文木解析 型・字句情報を用いて、 検出対象を発見する。 検出対象の抽象構文木の パターンを定義し、合致 するコードを探索する。 値の取りうる範囲から実際に整 数オーバーフローが起こりうる かを判定する。 C/C++ ソース コード 整数OF 可能性を 警告 検出対象 を探索 構⽂解析 未着手
20. 検出⼿法 > 抽象構⽂⽊解析 22 time_t 型 → int / long 型へのダウンキャストかを判定するアルゴリズム ① 抽象構文木に変換
21. 検出⼿法 > 抽象構⽂⽊解析 23 ② int / long 型のキャスト式を 見つける time_t 型 → int / long 型へのダウンキャストかを判定するアルゴリズム
22. 検出⼿法 > 抽象構⽂⽊解析 24 time_t 型 → int / long 型へのダウンキャストかを判定するアルゴリズム ③ 孫ノードまで再帰的に探索して キャスト元の型が time_t 型かどうか を判定する
23. 評価⼿法 25 検出ツールで発⾒したコードが、実際に2038年問題に起因する不具合を起こすかを確認 ツール配布 & 解析統計の収集 配布した検出ツールから解析結果を 収集し、大規模な脅威性評価を行う 実ソフトウェアへの解析 ・普及率の高いソフトウェア ・寿命の長い製品に用いられている ソフトウェア 2038年問題の 脅威性を評価 実装中 • 検出結果の統計 • 発⾒された重篤なバグ を提⽰
24. 0 100 200 300 400 500 600 700 800 900 検出したプロジェクト数 未検出だったプロジェクト数 評価 > 実ソフトウェアへの解析結果 26 874プロジェクト中 33.6% 3463 の該当表現 • GitHub 上のC言語リポジトリ • Star数上位 874 プロジェクト（16万〜約1300 Star） 評価結果 評価対象 ダウンキャストの検出数 ファイルタイムスタンプの検出数
25. 評価 > 検出例 27 現在時刻のダウンキャスト 外部出⼒時のダウンキャスト プログラム外部からの時刻データの ダウンキャスト 代入時ダウンキャスト 引数代入時ダウンキャスト 明示的ダウンキャスト
26. 評価 > False Positive 明らかに整数オーバーフローしないダウンキャスト • int x = time(NULL) % 60 • ダウンキャストはするが、64bit time_t のとき整数オーバーフローはしない • 改善案：値の取りうる範囲を考慮した解析手法（データフロー解析など）に改善 UNIX time 用途ではない time_t 型のダウンキャスト • タイムアウト秒数、時刻の差分などの用途でのtime_t 型も検出結果に含まれる • しかし、これはUNIX timeではないため、検出対象とすべきかは疑問 28
27. 評価⼿法 > 検出ツールの配布 & 解析統計の収集 利用者の解析情報を集計し，2038年問題の脅威性を統計評価する 29
28. C⾔語ソースコードに対して、抽象構⽂⽊解析によって検出するツールを Clangを⽤いて実装し、OSSに対する解析を⾏った。 今後の計画 30 2038年問題検出ツールの配布 データフロー解析の既存⼿法を調査、有⽤性の検証 既存ソフトウェアに対する検証 実際には整数OFしないのに検出された例もあり、提案手法の改善の必要性あり。 今ここ→ 2038年問題サイトの構築 修⼠論⽂の執筆 解析統計収集の仕組みの構築 検出ツールの広報、2038年問題に関する情報提供や啓蒙活動 今ここ→
29. まとめ 31 研究背景 2038年問題対策において、UNIX timeを64bit化する方法が一般的。しかし、単に 型を64bit化 するだけでは不十分で、ダウンキャストがあれば整数OFの可能性。これを見落としたシステ ムが世の中に多く存在し、脅威となるのでは？ 研究目的 2038年問題の原因となりうるC言語ソースコードを検出し、脅威性を評価する 本研究の貢献 874 の C言語OSS に対し、開発した検出ツールを用いて検証を実施した。 全体の 33.6% にあたる 294 のプロジェクトから 3463 の該当表現を発見した。 検出手法 AST解析 + データフロー解析 評価手法 既存ソフトウェアへの検証 + 2038年問題検出ツールの配布