Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Ran350
November 11, 2024
42

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

Ran350

November 11, 2024
Tweet

Transcript

  1. 本⽇のお品書き 前半 10分:検出ツールを作って脅威性評価してみた論文(星名) - 2038年問題と対策方法 - 64bit 化対策の落とし穴 - 2038年問題の脅威性評価

    論文 - 2038年問題 検出ツール OSS 後半5分:2038年問題のこれからについて議論(with 上原先生) 後半の時間では ご観覧の皆様からのご質問を受け付けます!
  2. 本⽇のお品書き 前半 10分:検出ツールを作って脅威性評価してみた論文(星名) - 2038年問題と対策方法 - 64bit 化対策の落とし穴 - 2038年問題の脅威性評価

    論文 - 2038年問題 検出ツール OSS 後半5分:2038年問題のこれからについて議論(with 上原先生) 後半の時間では ご観覧の皆様からのご質問を受け付けます!
  3. 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からの経過秒で 時刻を表現する形式
  4. 脅威が⼤きいという仮説 9 影響範囲はシステムの深層にまで至る • アプリケーションレイヤだけでなく、DB、OS、ファイルシステム、 言語処理系などUNIX timeを使用するすべてのソフトウェアが対象 • 提供側が対応すれば完了とはならない →ソフトウェア

    アップデートされない問題 →ソフトウェア アップデートできない問題(組込みシステムなど) 社会的認知度の低さ • 非技術者にとっての理解しづらさ • エンジニアだけでなく、経営者、行政の協力なしでは解決できない
  5. 2038年問題の対策 typedef int time_t; ※ 多くの環境で int 型は 32bit 符号付き整数型

    typedef long long time_t; ※ long long型は 64bit 符号付き整数型 32bit 64bit データ型を 64bit にすればよい?例えばC言語の場合、
  6. 2038年問題対応、型を64bit化するだけで済むか? 2038年問題対応したつもりでも 実は抜け漏れがあったというシナリオ 14 見落とし 実は UNIX timeが 32bit 符号付き整数型に

    なる処理が存在していた 2038年問題 発生 整数オーバフローが発生 不具合につながる 2038年問題対応の実施 UNIX time 用変数を 32bit整数型→64bit整数型 に再定義
  7. 検出⼿法 20 データフロー解析 抽象構文木解析 型・字句情報を用いて検出対象を 発見する手法。検出対象の抽象構 文木のパターン を定義し、合致 するコードを 探索する。

    値の取りうる範囲から実際に整 数オーバーフローが起こりうる かを判定する。 C/C++ ソース コード 整数OF 可能性を 警告 検出対象 を探索 構⽂解析 未着手
  8. 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 星名藍乃介、穐山空道、上原哲太郎(立命館大学)
  9. 本⽇のお品書き 前半 10分:検出ツールを作って脅威性評価してみた論文(星名) - 2038年問題と対策方法 - 64bit 化対策の落とし穴 - 2038年問題の脅威性評価

    論文 - 2038年問題 検出ツール OSS 後半5分:2038年問題のこれからについて議論(with 上原先生) 後半の時間では ご観覧の皆様からのご質問を受け付けます!
  10. 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