本記事では最近話題の「2038年問題」について解説します。2038年問題は狭義のサイバーセキュリティと関連するものではありませんが、そのまま放置してしまうとサイバーインシデントを引き起こす可能性がある問題となります。対応に準備に時間を要する問題であることから、読者の皆さまに早い段階から関心を持っていただければと考えています。
2000年問題を振り返る
初期のプログラミング言語（FORTRANやCOBOL注 1) など）はデータ型に日付型がなかったため、文字列を割り当てて日付として処理をしていました。
この時、日付を文字列で処理する際、1960年代～80年代の人類は自分が作ったプログラムがその後長く使われるなどと思わず、「とりあえずYY-MM-DDで表示すればデータ量削減にもなるし、いいだろう」と考え、慣例として西暦年を下２桁で処理していました。
図1：2000年問題の原因となった表示方法
何しろ今とは異なりCPUもメモリも、貧弱でも超高価な時代です。資源の節約は必要な限り実行しなければならない課題だったといえます。しかし、1990年代に入ったところで人類はふと気づきます。「これはもしや、西暦年の下２桁だけだと2000年になった時、処理上1900年に戻ってしまうのでは？」と。
図2：2000年問題
そうして、1990年代半ばからプログラムの書き換えが行われ、それまで下２桁だった西暦年を4桁に変更し、万が一の時のために1999年12月31日から2000年1月2日までの間、一部のIT業界の人たちが正月返上で出勤して不測の事態に備えたのが2000年問題です。
2000年問題では実際、2000年1月1日当日、特に何かが起こることはありませんでした。その背景は以下の通りです。
2000年問題が2000年1月1日に何も問題とならなかった背景
- COBOLやFORTRANなどのレガシー言語で古くに書かれたアプリケーションやマイコンなど対象が限定されていたこと
（※C言語などの比較的新しい言語は日付型をデータ型に持っていたため関係がなかった。） - 発生日が明確だったこと
- 対策が西暦年の2桁を4桁表示に変更するという方法に集約されていたこと
- 数年間にわたって事前の対策がとられていたこと
限定的な対象に対し、事前に入念な準備を行ったことが功を奏し、インシデントが発生しなかったことが2000年問題の結果です。
計算機とデータ型：2038年問題の技術的背景
さて2024年現在、コンピューター・タブレット端末・スマートフォンなど、見た目などから計算機であることがわかりづらいようになっていますが、やはりコンピューターは計算機です。実際アプリケーションを動かすにしてもプログラムがされていて、プログラムの実行には必ず計算が伴います。そして、プログラム上でデータを処理するためにはデータの種類を定めるデータ型というものがあります。
データ型の例
| データ型 | 例 |
|---|---|
| 文字列（str） | 今ご覧になっているいわゆる文字列のこと |
| 整数型（int） | 1, 2, 50, 1065, -5などの整数（負の数も含む） |
| 浮動小数点型（float） | 3.14, -0.001, 356.25などの小数点を含む数（負の数も含む） |
| ブーリアン型（bool） | 真（True）か偽（False）のいずれかで表わされる |
| 日付型（date） | 世界標準時（UTC）を基準として、1970年1月1日からの経過秒数を表すタイムスタンプデータ。整数型データで表わされる |
2000年問題のときはFORTRANやCOBOLに日付型が存在せず、文字型で処理していたこと、また限られた資源を節約するために下2桁で年を表していたことが原因でした。一方、2038年問題は日付型のタイムスタンプデータを格納する整数型のデータ長（ビット幅）の実装が原因となるものです。
SQAT.jpでは以下の記事で2024年版のプログラミング言語をめぐる状況と、ちょっとした脆弱性対策に関する情報をご紹介しています。こちらもあわせてご覧ください。
「【続】プログラミング言語の脆弱性対策を考える：2024」
2038年問題の技術的課題
符号付32ビット整数型から符号付64ビット整数型への移行の壁
前述したデータ型の例の表にもあるように日付型は絶対的な日付を表すものではなく、1970年1月1日午前0時0分を基準日時（エポックタイム）としてそこからの経過秒数をタイムスタンプデータとしてあらわすものです。C言語ではtime_tと呼ばれるこのデータでは、タイムスタンプデータを格納するのは符号付32bitの整数型となっています。符号付整数型は最初の1bitを正負符号のために使用します。符号の1ビットがあるため、実際に日付データ用に利用できるのは正負を表す最初の１ビットを除く31ビットで、利用できるビット長は（231-1）=2,147,483,647秒となります。よって基準日時からおよそ68年を上限として演算・表示ができるものとなります。
図3：符号付32bitであらわした2038年1月19日3時14分7秒
図3は1970年1月1日午前0時0分から2,147,483,647秒が経過した、2038年1月19日3時14分7秒（※うるう秒は考慮しておりません）の符号付32bit整数型でのtime_tの状態です。一番左側の符号0は正の値を表しており、1970年1月1日午前０時０分から2,147,483,647秒、正の方向に経過したことを示します。
さて、二進法の常で右側の31bitがすべて1になった場合、通常一番左側の1ビット目が1になります（二進法の繰り上がり）。
図4：符号付32bitのままで2038年1月19日3時14分8秒になった場合
1970年1月1日午前0時0分から2,147,483,648秒経過すると図4のようになります。符号付の場合、一番左側の符号1は負の値を表すため、1970年1月1日午前0時0分から2,147,483,647秒、負の方向に遡った1901年12月13日20時45分52秒を示します。つまり放置しておくと日付データが大きく誤ることとなります。この問題が最も深刻になるのは符号付32bitのtime_tを何らかの形で参照し、それを正しいものという前提で処理しているプログラムが、2038年1月19日の時点（または2038年1月19日以降の日付を参照する時点）で未改修のまま残ってしまうことで影響を及ぼしてしまうことなのです。
ウェビナー開催のお知らせ
「脆弱性診断の新提案！スピード診断と短納期で解決する「SQAT® with Swift Delivery」セミナー」
最新情報はこちら
2038年問題を回避する3つの対応策
対策として考えられる方法はいくつかありますが、根本的な対策は以下の3つになります。
- time_tを符号付64bit整数型に変更する
- time_tを符号なし32bit整数型に変更する
- time_tの基準日時を1970年1月1日午前0時0分から別の日時に移動する
主要OS・アプリケーションの2038年問題対応状況
2038年問題の影響が一番大きく出ると当初予想されていたのが各種OSです。以下に各OSの対応状況を記載します。
各OSの対応状況
| OS | |
|---|---|
| Linux | 64bitアーキテクチャ向けには当初より64bitのtime_tを提供。 32bitアーキテクチャについてはLinux Kernel 5.6で64bit化対応済み。5.4/5.5についてもバックポートで対応済み。*1 |
| FreeBSD | 原則として64bit対応済みだが、i386アーキテクチャの32bitアーキテクチャのみ非対応。I386アーキテクチャについては符号なしの32bit整数型 time_tを提供*2 |
| Windows | 64bitで1601年1月1日0時からの100n sec単位の差分計算をしていることから2038年問題は対象外といわれている*3 |
| macOS | macOS10.0(Cheetah)で基準時を2001年1月1日0時に変更しており、2038年問題は対象外。また、32bitアプリケーションはmacOS 10.15(Catalina)以降では使用できない*4 |
表にもある通り、最新のOSであればほぼ問題なく2038年問題をクリアできることがわかります。問題はOSの機能を補完する各種ドライバやライブラリ群、また、そのうえで動くアプリケーションでしょう。それぞれ確認は必要となりますが、代表的なものの対応状況は以下の通りです。
| ライブラリ/アプリケーション名 | 対応状況 |
|---|---|
| GNU C Library (glibc) | バージョン2.34でx86アーキテクチャ上での64bit整数型time-tに対応。ただしx86アーキテクチャ上のglibcのtime_t自体は32bitのままで、_TIME＿BITSプリプロセッサマクロが64に設定されていて、かつLFSが有効な場合にのみ利用可能などの制限あり*5 |
| NFS | NFSv4（RFC7530）秒単位のデータは符号付64bitであることが定義されている*6（※2.2.1 nfstime4の項を参照） |
| XFS | Linux 5.10でオプションとしてナノ秒単位を64bitで計算・表示する「big timestamps」を追加し、2486年まで対応できるように修正。ただしデフォルトで追加が反映されるものではなく有効に設定する必要がある*7 |
| MySQL | 8.0.28でFROM_UNIXTIME(), UNIX_TIMESTAMP(), CONVERT_TZ() の64bit対応。ただしOS側が64bit対応である必要あり（いずれの関数もOSの日付型データを参照するため）*8 |
| MariaDB | 11.5.1でタイムスタンプを2106年02月07日6時28分15秒まで拡張*9 |
| Visual C++ | 32bitであえて指定されていない限りは64bitがデフォルト値*10 |
上記はごく一部の対応状況ですが、仮に対応していても制限事項がつくものが存在する点に注意が必要です。ここまで記載した内容で何となくお気づきの方もいらっしゃるかもしれませんが、2038年問題は発生する可能性がある箇所が2020年問題に対して格段に多いため、時間がかかることが予想されます。
2000年問題と2038年問題の違い
- 対象がOS/ライブラリからアプリケーション、機器類まで非常に幅が広い
- 2000年当時に比べて格段にデジタル化が進んでいる
- 対策方法が一様ではないものや、現在動いているシステムに対して即時変更をかけられないものがある
企業が取るべき2038年問題対策：自社システムの診断方法
自社のプログラムの調査は?
さて、「PCやサーバなんかを買ってきたものの、自社で作ったものはどうすればいいの？」というケースもあるでしょう。自社で作ったものは…そうです。自分たちで調べるしかないのです。実際に調査をして対応をした事例がまとめられた論文が公開されています。
組込み機器開発における2038年問題への対応事例
https://www.ipsj.or.jp/dp/contents/publication/39/S1003-1809.html
この事例では製品のライフサイクルがもともと20年前後を想定していることから、まずは2038年を最低限クリアすることを要件として調査を開始しています。このケースは組み込み機器になりますが、その単体の機器でもOS部分を含む総行数330万行のコードから符号付32bit整数型のtime_tを明示的に使用する箇所およそ3500か所が発見されています。
この事例でとられたステップを簡単にまとめます。
この事例では3500か所に対して5.8人月で実行された修正作業もさることながら、そのレベルの工数で抑制するために事前の洗い出しや対策案の立案、修正作業の手順策定といったところの重要さが感じられます。特に対策案を選定するにあたって要件が明確だったことが対策案の選定を容易にしたことがわかることから、作業開始前（せめて対策案の選定前）に要件を明確にしておくことの重要さを実感させられます。
さて、2038年問題に該当するコードを検出するためのツールは日本の研究者も含め、いくつかのGitHubレポジトリからリリースされています。最近では立命館大学のサイバーセキュリティ研究室によるY2k38チェッカーがリリースされています。
Y2k38チェッカーチェッカー作者によるプレゼン資料
こういったチェッカーは自社開発のプログラム資産のざっとしたチェックに使えるでしょう。また、チェッカー以前の問題として、まずは自社のプログラム資産が2038年問題の影響を受けないか、そろそろ確認を行い、準備を始める期間に入ってきたといえるかもしれません。
組み込み機器とは？：2038年問題の最大の影響
実はここまでにあまり触れていない、最大の2038年問題があります。それは、先ほどの論文の事例にもある組み込み機器の問題です。
組み込み機器といわれてもピンとこない方もいらっしゃるかもしれません。身近な例でいうと家電製品を制御するために組み込まれているコンピューターになります。一番パソコンに近いものであれば最近のハードディスク内蔵か外付け対応のテレビが挙げられます。このほかにも例えば電車に乗るときの自動改札機、切符販売機、水道や電気ガスなどのメーター類や街中で見かけるデジタルサイネージなども組み込み機器です。ほかにも工場のセンサー類やオートメーション用の機器類、配電設備や浄水・配水設備などのインフラ設備、病院の検査機器などにも組み込み機器が用いられています。
先ほどの事例のようにライフサイクルが決まっていて、そのライフサイクルの間のみ使用するというのが利用者（消費者）側に正しく認識されていれば問題ないのですが、実際のところ、組み込み機器こそライフサイクルを超えて、転売などをされて使い続けられるケースが多く、販売業者も製造業者もすべての出荷品の現状をトレースできないケースがあるといわれています。特に償却期間が5年を超えるような固定資産については入れ替えの検討なども含めて対応する必要が出てくることから、そろそろ取りまとめを始めなければならないでしょう。また、個人向けのIoT機器や家電のように、長期間の利用は想定されていない（売り切りに近い）製品については直前になって買い替えが必要といったアナウンスが出てくる可能性もあるでしょう。
サイバーインシデント緊急対応
まとめ
2038年問題は日付データが誤ることで社会的に大きな影響を与える可能性があります。本記事公開日（2024年12月）時点ではまだまだ先の問題と思っている方が多いと思いますが、そろそろロードマップを書き始めないと対策に取る時間が足りなくなる可能性があります。これを念頭に置き、早めの対策方法を考えておく必要があるでしょう。
Security Report TOPに戻る
TOP-更新情報に戻る
注：
1)FORTRAN
・数学分析用を目的としたプログラミング言語
・データ型は整数、実数、複素数、文字、論理の５種類
COBOL
・1950年代終わりに開発されたプログラミング言語
・データ型は文字、数字、数字編集の３種類
