2038年問題が思ったよりヤバい。検出ツールを作って脅威性評価してみた論文 | Kansai Open Forum 2024

Transcript

1. 2024/11/9 関西オープンフォーラム2024 立命館大学 情報理工学研究科 サイバーセキュリティ研究室 上原哲太郎、星名 藍乃介 2038年問題が思ったよりヤバい。 検出ツールを作って脅威性評価してみた論⽂
2. 本⽇のお品書き 前半 10分：検出ツールを作って脅威性評価してみた論文（星名） - 2038年問題と対策方法 - 64bit 化対策の落とし穴 - 2038年問題の脅威性評価 論文 - 2038年問題 検出ツール OSS 後半5分：2038年問題のこれからについて議論（with 上原先生） 後半の時間では ご観覧の皆様からのご質問を受け付けます！
3. 本⽇のお品書き 前半 10分：検出ツールを作って脅威性評価してみた論文（星名） - 2038年問題と対策方法 - 64bit 化対策の落とし穴 - 2038年問題の脅威性評価 論文 - 2038年問題 検出ツール OSS 後半5分：2038年問題のこれからについて議論（with 上原先生） 後半の時間では ご観覧の皆様からのご質問を受け付けます！
4. 2038年問題とは 6 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からの経過秒で 時刻を表現する形式
5. 2038年問題を抱えるソフトウェアたち
6. ೥໰୊͸ڴҖʹͳΓ͏Δ͔ʁ 8
7. 脅威が⼤きいという仮説 9 影響範囲はシステムの深層にまで至る • アプリケーションレイヤだけでなく、DB、OS、ファイルシステム、 言語処理系などUNIX timeを使用するすべてのソフトウェアが対象 • 提供側が対応すれば完了とはならない →ソフトウェア アップデートされない問題 →ソフトウェア アップデートできない問題（組込みシステムなど） 社会的認知度の低さ • 非技術者にとっての理解しづらさ • エンジニアだけでなく、経営者、行政の協力なしでは解決できない
8. 2038年問題の対策 32bit UNIX time の最大値： 2038年 64bit UNIX time の最大値：西暦 約3000億年
9. 2038年問題の対策 typedef int time_t; ※ 多くの環境で int 型は 32bit 符号付き整数型 typedef long long time_t; ※ long long型は 64bit 符号付き整数型 32bit 64bit データ型を 64bit にすればよい？例えばC言語の場合、
10. これで2038年問題対応は完璧︖ 12
11. 2038年問題対応、型を64bit化するだけで済むか？ 13 変数代入時のダウンキャスト return 時の 暗黙的ダウンキャスト 関数の引数代入時 の 暗黙的ダウンキャスト 明示的なダウンキャスト typedef long long time_t; でも 64bit → 32bit型へキャストすると☠
12. 2038年問題対応、型を64bit化するだけで済むか？ 2038年問題対応したつもりでも 実は抜け漏れがあったというシナリオ 14 見落とし 実は UNIX timeが 32bit 符号付き整数型に なる処理が存在していた 2038年問題 発生 整数オーバフローが発生 不具合につながる 2038年問題対応の実施 UNIX time 用変数を 32bit整数型→64bit整数型 に再定義
13. 6/*9
    UJNF
    ͕ Ұ؏ͯ͠CJUΛ௒͍͑ͯΔ͔Λ ໢ཏతʹௐ΂ͳ͍ͱ͍͚ͳ͍ 15
14. େม 😵💫 16
15. ࣗಈԽͰ͖ͳ͍͔ʁ 17
16. ͭͬͨ͘ʂ 18
17. y2k38-checker https://github.com/cysec-lab/y2k38-checker Clang コンパイル時にプラグインとして与える おなじみの Clang 警告として教えてくれる C⾔語ソースコードから2038年問題可能性のあるコードを検出する
18. 検出⼿法 20 データフロー解析 抽象構文木解析 型・字句情報を用いて検出対象を 発見する手法。検出対象の抽象構 文木のパターン を定義し、合致 するコードを 探索する。 値の取りうる範囲から実際に整 数オーバーフローが起こりうる かを判定する。 C/C++ ソース コード 整数OF 可能性を 警告 検出対象 を探索 構⽂解析 未着手
19. 0 100 200 300 400 500 600 700 800 900 検出したプロジェクト数 未検出だったプロジェクト数 脅威性評価してみた論⽂ 21 874プロジェクト中 33.6% 3463 の該当表現 • GitHub 上のC言語リポジトリ • Star数上位 874 プロジェクト 評価結果 評価対象 論文「32bitを超えるtime_t型を持つ環境における2038年問題とその検出」 情報処理学会 論文誌 Vol.65 No.9 星名藍乃介、穐山空道、上原哲太郎（立命館大学）
20. 評価 > 検出例 22 現在時刻のダウンキャスト 外部出⼒時のダウンキャスト プログラム外部からの時刻データの ダウンキャスト 代入時ダウンキャスト 引数代入時ダウンキャスト 明示的ダウンキャスト
21. ͜ͷ݁ՌΛ;·͑ͯɺ զʑ͸ࠓޙͲ͏͍ͯ͘͠΂͖͔ʁ 23
22. 本⽇のお品書き 前半 10分：検出ツールを作って脅威性評価してみた論文（星名） - 2038年問題と対策方法 - 64bit 化対策の落とし穴 - 2038年問題の脅威性評価 論文 - 2038年問題 検出ツール OSS 後半5分：2038年問題のこれからについて議論（with 上原先生） 後半の時間では ご観覧の皆様からのご質問を受け付けます！
23. 2038年問題のこれからについて議論（with 上原先⽣） ご観覧の皆様からのご質問を受け付けます！ 1. 特に影響が大きい、修正が大変そうなレイヤは？ 2. 2038年問題ソフトウェア一覧表から、特に注目しているものは？ 3. 2038年まであと14年、まだまだ先の話？ 4. 2038年問題対応の難しいところは？ 5. 64bit 化での対応ではなく、uint32化する対応はどうか？ 25
24. 2038年問題の難しさ • どこまで影響があるか結局よくわからないけど確実に影響があることだけはわかる • しかし「普通の⼈」にリスクの⼤きさが伝わらない • 対策が難しい • time_tを64bitにしてコンパイルしなおせるシステムはそれほど多くなさそう • 32bitで蓄積されたデータをそのまま使わざるを得ないシステムは多々ある • 頑張って64bitにしてもハマりどころは多い • そもそもtime_t以前のシステムがいっぱいある • 32bitのまま対処するしかないかもしれないが「統⼀的な」対処法がない • time_tをunsignedにすると先送りできるが「時間差」計算が問題になる • time値の差はdifftime()使わないといけないのだけど単に引き算してるコードは多々ある • その場合time_t a,b;においてa-bが負数だった場合の処理があればunsignedにした途端動かない • Epochをずらす⼿法は提案されているが業界的に統⼀された値はない • ラップラウンドさせる（負数になっていたらEpochを2106年2⽉7⽇6時28分16秒とみなす) • 意外と「ちゃんと研究」されてない 26