Il est fort possible que beaucoup d’entre vous se souviennent encore de la confusion générée par ce que l’on appelle l’effet Y2K au tournant du siècle, il y a plus de deux décennies. Eh bien, maintenant nous vous disons que c'est quelque chose qui pourrait se reproduire dans quelques années également dans le secteur technologique.
Et certaines entreprises nous préviennent désormais qu'un bon nombre d'équipements et de systèmes pourraient commencer à se comporter de manière imprévisible. 19 janvier 2038. Les problèmes possibles incluent des erreurs de traitement des paiements par carte, de fausses alarmes de sécurité, des dysfonctionnements des équipements médicaux, etc. Même s’il reste quelques années, ce n’est pas une raison pour se relâcher, car le temps disponible pour se préparer pourrait s’avérer insuffisant.
La cause de cette avalanche de problèmes sera un débordement des entiers qui stockent les date et heure de l'équipement. Bien que la cause première de l’erreur soit simple et claire, sa correction nécessitera beaucoup d’efforts à tous les niveaux. Cela affectera les gouvernements et les organisations internationales, ainsi que les entreprises et les utilisateurs finaux.
Débuts de l'erreur dans les dates et heures
Il faut savoir qu'au moment de Unixle système de chronométrage adopté par ces systèmes d'exploitation est devenu populaire dans tous les environnements technologiques. Cela compte les secondes à partir de 00:00:00 UTC le 1er janvier 1970, considéré comme le point zéro. Pour les dates antérieures à 1970, des valeurs négatives sont utilisées. Cette approche a été choisie par les développeurs Unix pour sa simplicité. De nos jours, tout cela est utilisé bien au-delà des systèmes Unix, c'est courant dans bases de donnéeslangages de programmation, protocoles réseau et même sur les appareils iOS et Android.
Mais au début, avec cette méthode, il a été décidé de stocker l’heure sous forme d’entier signé de 32 bits. Cela nous a permis de représenter une plage de dates allant approximativement de 1901 à 2038. Le problème est que le 19 janvier 2038, à 03:14:07 UTC, ce nombre atteindra sa valeur maximale et débordera, devenant négatif. D'où l'erreur qui se produira à ce moment-là.
Cet événement, connu sous le nom de problème de l'année 2038 ou Y2K38pourrait provoquer des erreurs comme celles que nous avons mentionnées précédemment. Ils affecteront les terminaux de point de vente, les systèmes intégrés et les routeurs, les voitures et les équipements industriels.
Solutions pour l'effet Y2K38
Il faut savoir que les systèmes modernes résolvent ce problème en utilisant 64 bits pour stocker la date et l'heure. Par conséquent, si nous disposons d’un système d’exploitation avec cette architecture 64 bits, nous n’aurons aucun problème. Cependant, des millions d'ordinateurs dotés de données 32 bits sont toujours en fonctionnement et nécessiteront une mise à niveau ou un remplacement avant l'arrivée de ce jour. Dans les cas où il n'est pas nécessaire de gérer les dates antérieures à 1970, la date est stockée sous la forme d'un entier non signé de 32 bits. Ce type peut représenter date de 1970 à 2106.
Dans le même temps, la principale différence entre l’an 2003 et l’an 2000 ou l’effet an 2000 réside dans l’ampleur de la numérisation dans nos vies. Le nombre de systèmes qui auront besoin de mises à jour aujourd’hui est bien plus important qu’en 2000.
À ce stade, comme nous le savons désormais, les bases permettant de résoudre le problème de l’an 200038 ont été établies avec succès dans les principaux systèmes d’exploitation. Le noyau Linux ajouté Prise en charge 64 bits même sur les architectures 32 bits à partir de la version 5.6, en 2020. Dans le même temps, des langages tels que Java, Python et Go utilisent souvent des types qui empêchent le débordement de mémoire, mais la sécurité des projets compilés dépend de leur interaction avec des bibliothèques vulnérables écrites en C.
Et un grand nombre de systèmes, d'appareils et applications 32 bitsrestent vulnérables à cet échec. Désormais, les méthodes créées pour corriger les vulnérabilités sont applicables au problème de l'année 2038. Le principal défi est qu’aujourd’hui aucun outil ne peut créer une liste de logiciels et de matériels vulnérables.
| Aspect | An 2000 (effet 2000) | Y2K38 (numéro 2038) |
|---|---|---|
| Cause technique | Stockage de l'année avec 2 chiffres (par exemple 99 pour 1999) | Débordement d'un compteur de secondes en un entier signé de 32 bits |
| Date critique | 1er janvier 2000, 00:00:00 UTC | 19 janvier 2038, 03:14:07 UTC |
| Systèmes vulnérables | Principalement des mainframes (COBOL) et des logiciels existants | Systèmes embarqués, IoT, routeurs, équipements industriels et tout système POSIX 32 bits |
| Solution principale | Agrandissez le champ de l'année à 4 chiffres (AAAA) | Migrer le matériel et les logiciels vers une architecture 64 bits |
| Complexité | Laborieux mais conceptuellement simple (trouver et remplacer) | Complexe, nécessite des modifications architecturales et peut rompre la compatibilité binaire |
Il est essentiel de mettre à jour l’inventaire des actifs de l’entreprise et de veiller à ce qu’il soit complété par des informations détaillées sur les micrologiciels et logiciels installés sur les ordinateurs vulnérables. Ici, vous devrez établir des priorités en fonction du degré de critique des systèmes d'entreprise et des données utilisées par chaque système. Ensuite, consultez le support du fournisseur, discutez avec les fabricants de matériel et de logiciels de leur statut Y2K38 et, en dernier recours, vérifiez tout via des tests.