Epochalypse Now – ou comment gérer le bug de l’an 2038

Des millions de systèmes informatiques, dont certains industriels et liés à l’IdO, pourraient commencer à présenter un comportement erratique le 19 janvier. Voici quelques exemples de défaillances potentielles : problèmes techniques lors du traitement des paiements par carte bancaire ; fausses alertes des systèmes de sécurité ; dysfonctionnement des équipements médicaux ; défaillances des systèmes automatisés d’éclairage, de chauffage et d’alimentation en eau ; et bien d’autres types d’erreurs plus ou moins graves. Le hic, c’est que cela se produira le 19 janvier 2038. Ce n’est pas une raison pour baisser la garde, car le temps restant pour se préparer pourrait déjà être insuffisant. La cause de cette multitude de problèmes réside dans un débordement des entiers stockant la date et l’heure. Même si la cause profonde de l’erreur est simple et claire, sa correction nécessitera des efforts considérables et systématiques à tous les niveaux, tant au sein des gouvernements et des organismes internationaux qu’au sein des entreprises et des particuliers.

La norme non écrite de l’époque Unix

L’époque Unix est le système de mesure du temps adopté par les systèmes d’exploitation Unix, et qui s’est popularisé dans l’ensemble du secteur informatique. Il compte les secondes à partir de 00:00:00 UTC le 1ᵉʳ janvier 1970, qui est considéré comme le point zéro. Chaque instant donné est représenté par le nombre de secondes écoulées depuis cette date. Des valeurs négatives sont utilisées pour les dates antérieures à 1970. Cette approche a été choisie par les développeurs Unix pour sa simplicité : au lieu de stocker séparément l’année, le mois, le jour et l’heure, un seul nombre suffit. Elle facilite les opérations comme le tri ou le calcul de l’intervalle entre deux dates. Aujourd’hui, l’époque Unix est utilisée bien au-delà des systèmes Unix : dans les bases de données, les langages de programmation, les protocoles réseau et les smartphones fonctionnant sous iOS et Android.

La bombe à retardement de l’an 2038

Au départ, lors du développement d’Unix, le choix a été fait de stocker le temps sous forme d’entier signé 32 bits. Cela a permis de représenter une période allant approximativement de 1901 à 2038. Le problème est que le 19 janvier 2038, à 03:14:07 UTC, ce nombre atteindra sa valeur maximale (2 147 483 647 secondes) et débordera, devenant négatif, ce qui provoquera une « téléportation » des ordinateurs de janvier 2038 au 13 décembre 1901. Cependant, dans certains cas, un « voyage dans le temps » plus court pourrait avoir lieu, jusqu’au point zéro, qui correspond à l’année 1970.

Cet événement, connu sous le nom de « bug de l’an 2038 », « Epochalypse » ou « Y2K38 », pourrait entraîner des défaillances dans les systèmes qui continuent d’utiliser une représentation temporelle 32 bits, qu’il s’agisse de terminaux de point de vente, de systèmes embarqués, de routeurs, d’automobiles ou d’équipements industriels. Les systèmes modernes règlent ce problème en utilisant l’architecture 64 bits pour stocker l’heure. Celle-ci étend la période à des centaines de milliards d’années dans le futur. Cependant, des millions d’appareils utilisant des dates 32 bits sont toujours en service et devront être mis à jour ou remplacés avant l’arrivée du « jour J ».

Dans ce contexte, les notions de 32 et 64 bits font référence au format de stockage des dates. Ce n’est pas parce qu’un système d’exploitation ou un processeur fonctionne en 32 bits ou 64 bits qu’il stocke automatiquement la date dans son format binaire « natif ». De plus, de nombreuses applications stockent les dates de manière complètement différente et pourraient être immunisées contre le bug de l’an 2038, quelle que soit leur architecture.

Lorsqu’il n’est pas nécessaire de traiter des dates antérieures à 1970, la date est stockée sous forme d’entier 32 bits non signé. Ce type de nombre peut représenter des dates comprises entre 1970 et 2106, le problème se posera donc dans un avenir plus lointain.

Différences par rapport au bug de l’an 2000

Le tristement célèbre bug de l’an 2000 (Y2K) de la fin du 20^e siècle était similaire en ce sens que les systèmes stockant l’année sous forme de deux chiffres pouvaient confondre la nouvelle date avec l’année 1900. Les experts et les médias craignaient une apocalypse numérique, mais finalement, seuls quelques incidents isolés se sont produits, sans entraîner de défaillance catastrophique à l’échelle mondiale.

La principale différence entre le bug de l’an 2038 et celui de l’an 2000 réside dans l’ampleur de la numérisation dans nos vies. Le nombre de systèmes qui devront être mis à jour est bien supérieur au nombre d’ordinateurs au 20^e siècle, et le nombre de tâches et de processus quotidiens gérés par les ordinateurs est incalculable. Entre-temps, le bug de l’an 2038 a déjà été résolu, ou le sera bientôt, dans les ordinateurs et les systèmes d’exploitation courants grâce à de simples mises à jour logicielles. Cependant, les micro-ordinateurs qui gèrent les systèmes de climatisation, les ascenseurs, les pompes, les serrures et les chaînes de montage dans les usines pourraient très bien continuer à fonctionner au cours de la prochaine décennie avec des versions logicielles obsolètes et vulnérables au bug de l’an 2038.

Problèmes potentiels liés à l’Epochalypse

Le passage à l’an 1901 ou 1970 aura des répercussions différentes selon les systèmes. Dans certains cas, comme celui d’un système d’éclairage programmé pour s’allumer tous les jours à 19 heures, il peut passer totalement inaperçu. Dans d’autres systèmes qui reposent sur des horodatages complets et précis, une panne totale pourrait se produire. Par exemple, en l’an 2000, les terminaux de paiement et les tourniquets des transports publics ont cessé de fonctionner. Des situations cocasses sont également imaginables, comme la délivrance d’un acte de naissance avec une date de 1901. La défaillance de systèmes critiques, comme l’arrêt complet d’un système de chauffage ou la défaillance d’un système d’analyse de la moelle osseuse dans un hôpital, serait bien plus grave.

La cryptographie joue un rôle important dans l’Epochalypse. Une autre différence cruciale entre 2038 et 2000 est l’omniprésence du chiffrement et des signatures numériques pour protéger toutes les communications. La vérification des certificats de sécurité échoue généralement si la date de l’appareil est incorrecte. Cela signifie qu’un appareil vulnérable serait coupé de la plupart des communications, même si ses applications professionnelles de base ne comportent aucun code traitant incorrectement la date.

Malheureusement, l’éventail complet des conséquences ne peut être déterminé que par des essais contrôlés de tous les systèmes, avec une analyse séparée d’une cascade potentielle de défaillances.

L’exploitation malveillante du bug de l’an 2038

Les équipes informatiques et de sécurité devraient considérer le bug de l’an 2038 non pas comme une simple anomalie logicielle, mais comme une vulnérabilité susceptible d’entraîner diverses pannes, y compris un déni de service. Dans certains cas, des acteurs malveillants peuvent même en profiter. Pour ce faire, ils doivent pouvoir manipuler l’heure sur le système en cause. Cette situation est possible dans au moins deux cas de figure :

• Interférer avec les données du protocole NTP en fournissant au système ciblé un faux serveur de temps
• Usurpation du signal GPS – si le système repose sur l’heure par satellite

L’exploitation de cette erreur est plus probable dans les systèmes OT et IdO, où les vulnérabilités tardent généralement à être corrigées, et où les conséquences d’une défaillance peuvent être beaucoup plus importantes.

Un exemple de faille facilement exploitable liée au calcul de l’heure est la vulnérabilité CVE-2025-55068 (CVSSv3 8.2, CVSSv4 base 8.8) dans les consoles de jauge de réservoir de carburant automatique Dover ProGauge MagLink LX4. La manipulation de l’heure peut provoquer un déni de service à la station-service et bloquer l’accès au panneau de gestion Web de l’appareil. Ce problème a fait l’objet d’un avis de la CISA.

État actuel des mesures de prévention du bug de l’an 2038

Les bases de la résolution du bug de l’an 2038 ont été posées dans les principaux systèmes d’exploitation. Le noyau Linux a ajouté la prise en charge d’une représentatoin du temps en 64 bits, même sur les architectures 32 bits, à partir de la version 5.6 en 2020, et les distributions Linux en version 64 bits ont toujours été protégées contre ce problème. La famille BSD, macOS et iOS utilisent l’architecture 64 bits pour calculer l’heure sur tous les appareils modernes. Toutes les versions de Windows sorties au 21^e siècle ne sont pas vulnérables au bug de l’an 2038.

En revanche, la situation est bien plus complexe sur le plan du stockage des données et des applications. Les systèmes de fichiers modernes comme ZFS, F2FS, NTFS et ReFS ont été conçus avec des horodatages sur 64 bits, tandis que les systèmes plus anciens, comme ext2 et ext3, restent vulnérables. Les systèmes Ext4 et XFS impliquent l’activation d’options spécifiques (extended inode pour ext4 et bigtime pour XFS), ce qui peut exiger une conversion hors ligne des systèmes de fichiers existants. Dans les protocoles NFSv2 et NFSv3, le format de stockage de l’heure obsolète persiste. On retrouve une situation similaire dans les bases de données : le type TIMESTAMP de MySQL est fondamentalement limité à l’année 2038 et nécessite une migration vers DATETIME, tandis que les types d’horodatage standard de PostgreSQL sont sûrs. Pour les applications écrites en C, des chemins ont été créés pour représenter le temps en 64 bits sur des architectures 32 bits, mais tous les projets exigent une recompilation. Les langages tels que Java, Python et Go utilisent généralement des types de données qui évitent le débordement, mais la sécurité des projets compilés dépend de leur interaction avec des bibliothèques vulnérables écrites en C.

Un très grand nombre de systèmes 32 bits, d’appareils embarqués et d’applications restent vulnérables jusqu’à ce qu’ils soient recompilés et testés, et que des mises à jour soient installées par tous leurs utilisateurs.

Diverses organisations et passionnés tentent de systématiser les informations à ce sujet, mais leurs efforts sont fragmentés. Par conséquent, il n’existe pas de « base de données commune des vulnérabilités du bug de l’an 2038 » (1, 2, 3, 4, 5).

Approches visant à résoudre le bug de l’an 2038

Les méthodologies créées pour hiérarchiser et corriger les vulnérabilités sont directement applicables au problème de l’an 2038. Le principal défi réside dans le fait qu’aucun outil ne permet aujourd’hui de dresser une liste exhaustive des logiciels et du matériel vulnérables. Il est donc essentiel de mettre à jour l’inventaire des équipements informatiques de l’entreprise, de veiller à ce que celui-ci soit accompagné d’informations détaillées sur les micrologiciels et les logiciels installés, puis d’enquêter systématiquement sur la question des vulnérabilités.

La liste peut être établie par ordre de priorité en fonction de la gravité des systèmes d’entreprise et des données relatives à la pile technologique sur laquelle chaque système est construit. Voici les étapes suivantes : étudier le portail d’assistance du fournisseur, se renseigner directement auprès des fabricants de matériel et de logiciels sur leur état par rapport au bug de l’an 2038 et, en dernier recours, procéder à une vérification par des tests.

Les tests de systèmes d’entreprise exigent des précautions particulières :

• Ne jamais tester les systèmes de production.
• Créer une sauvegarde des données juste avant le test.
• Isoler le système testé de toute communication afin qu’il ne puisse pas perturber les autres systèmes de l’organisation.
• Si le changement de date utilise le protocole NTP ou le système GPS, assurez-vous que les signaux de test 2038 ne peuvent pas atteindre d’autres systèmes.
• Après le test, remettez les systèmes à l’heure et documentez soigneusement tous les comportements observés.

Si un système s’avère vulnérable au bug de l’an 2038, il est nécessaire de demander au fournisseur un plan d’action pour y remédier. Si une correction est impossible, prévoyez une migration. Heureusement, le temps qu’il nous reste permet encore de mettre à jour même des systèmes assez complexes et coûteux.

Le plus important dans la lutte contre le bug de l’an 2038 est de ne pas penser qu’il s’agit d’un problème lointain dont la solution peut facilement attendre encore cinq à huit ans. Il est fort probable qu’il soit déjà trop tard pour éradiquer complètement le défaut. Toutefois, au sein d’une organisation et de son parc technologique, il est possible d’y parvenir à temps en procédant à une planification minutieuse et en adoptant une approche systématique pour résoudre le problème.