Ce 1er janvier 2022 à 0h00 UTC, les serveurs Microsoft Exchange ont gelé le transport de tous les e-mails, expliquent BornCity et BleepingComputer, notamment.
Exchange vérifie en effet la version du moteur d'analyse antivirus FIP-FS et tente de stocker la date dans une variable int32 signée. Or, cette variable ne peut stocker qu'une valeur maximale de 2 147 483 647, ce qui est inférieur à la nouvelle valeur de date de 2 201 010 001 pour le 1er janvier 2022, à minuit.
Microsoft a depuis publié un correctif temporaire nécessitant une action du client, tout en travaillant sur une mise à jour qui résoudrait automatiquement le problème. Microsoft prévient que ce processus peut prendre un certain temps, selon la taille de l'organisation.
Après avoir exécuté le script, Microsoft indique en effet que les e-mails recommenceront à être livrés, mais que cela peut prendre un certain temps en fonction de la quantité d'e-mails bloqués dans la file d'attente.
Commentaires (35)
#1
Ça m’a fait bosser le 1er ! Merci Microsoft de ne jamais nous décevoir en nous offrant le bug de l’an 2022…
#2
Quelles bonnes idées, ils ont les développeurs !
utiliser un signé pour stocker ce genre d’infos comme les dates ! En plus, ça ne permet pas de stocker les dates avant l’an 0 puisque seuls les 2 derniers chiffres de l’année sont stockés.
stocker une date/heure sous une forme BCD mais uniquement sur 32 bits au 21ème siècle : le format a forcément été choisi pour ce siècle, puisque seuls les 2 derniers chiffres de l’année sont stockés. Oui, je me répète, mais vu le format utilisé, ça fait 2 mauvaises décisions pour les mêmes raisons.
#2.1
Merci d’avoir noté la notation BCD, parce que moi causant en timestamp là j’étais perdu
#3
Pfff, toujours à râler. Le mec il a ultra optimisé son format de date pour être géré super rapidement et on se plaint …
Jamais contents les utilisateurs…
#3.1
HS à part, je serai curieux de voir la réelle différence de perf entre le décodage de leur BCD, et la lecture d’un vrai timestamp ;)
Bon j’ai pas grand chose à faire aujd, je voir si je trouve 30min de creux pour coder ça :p
#4
Rendez-vous en 2038 pour un message du même genre…
#5
Seulement sur les systèmes UNIX/Linux 32 bits (et de toute façon, ça a été patché pour utiliser un entier non signé). On peut espérer que ce genre de systèmes ne sera plus employé dans 16 ans…
#6
Alors là… je serais moins confiant. Il parait qu’il y a encore beaucoup de code NT 4.0 dans Windows 10…
#7
Ballot de se faire avoir sur un int32
C’est pas comme s’il y avait eu des précédents
Heureusement Exchange n’est pas un service critique pour beaucoup de sociétés /s
#8
Les 2 dernières semaines de 2021 j’ai bossé sérieusement sur mon DAG Exchange pour le mettre au propre (nettoyage, changement de firewall dédié, vidange de logs pas faite depuis 1 an, plusieurs modifications de configurations pour tout mettre propre suite au passage du script HealthChecker, sauvegardes, etc…). Bref un gros chantier. Le 31 je quitte le bureau confiant et satisfait d’avoir fait du bon travail.
Le dimanche matin 2 janvier… plus de mails pro sur mon smartphone depuis le milieu de la veille
Vent de panique…. bordel mais qu’est ce que j’ai fait comme connerie… je vais me faire lyncher lundi matin… 3h de recherches… Désespoir… Et puis subitement j’ai eu l’idée de taper une recherche sur google avec les mots choisis … soulagement… délivrance… Apéro…
#9
Il n’y a malheureusement pas que les systèmes UNIX qui utilisent des timestamps UNIX…
#9.1
Pourquoi malheureusement ? En 64 bits, il n’y aura pas de problème avant très très longtemps et en 2038, les machines 32 bits, il ne devrait plus y en avoir beaucoup.
#9.2
C’est là que tu te plantes, je pense. Dans l’embarqué, le 32 bits est toujours la norme, et certains de ces systèmes, déployés aujourd’hui, ne sont toujours pas compatibles avec les années > 2038. Et la durée de vie de certains de ces équipements fait qu’il va falloir procéder à leur mise à jour à un moment (ou, plus vraisemblablement, à un remplacement prématuré :/ ).
#9.4
Dommage, j’ai bossé essentiellement dans l’embarqué.
Les gens qui font ces choix ne sont peut-être pas très raisonnables, ne serait-ce que pour la disponibilité des pièces de rechanges.
Et pour répondre aux 2 : on parle quand même d’un problème qui va se passer dans 16 ans et quelques jours, ça laisse le temps de se débarrasser de ces produits qui seront très largement amortis.
#9.5
Pourquoi « dommage » ? L’embarqué, ça regroupe tellement de choses différentes que tu peux très bien ne pas être concerné par le problème (typiquement, parce que les appareils n’ont pas de RTC) qu’au contraire, y être particulièrement sensible (parce que tu as besoin d’horodater précisément, comme un distributeur bancaire).
Pour parler de ce que je pratique tous les jours, dans xenomai, la compatibilité 2038 sur architecture 32 bits, c’est un travail en cours (basé sur les travaux Linux, lesquels viennent à peine de se terminer). Donc tout ce qui sort aujourd’hui, et pour encore quelques années (le temps que ça migre) devra être renouvelé / patché avant 2038. Ce n’est pas insurmontable, mais tout ça s’accumule dans la nature. Quand tu vois les distributeurs de billet toujours sous windows XP, l’inertie ce n’est pas quelque chose à négliger.
J’ai toujours pensé que l’année 2037 et le début 2038 seraient l’occasion de me faire une grosse prime avant la retraite, du fait de tous les systèmes critiques qu’il faudra auditer / corriger. Bon, depuis, ils ont repoussé l’âge de la retraite…
#9.3
Toi tu doit pas trainer souvent dans l’industrie!
J’ai encore des superviseurs qui tournent sous Windows 3.1 chez des clients!
Je ne sais plus si une MaJ a été faite pour XP pour signer le timestamp… mais des XP j’en ai encore quelques dizaines en production! (pour les mainframe que je croise encore style AS400, je suis pas sûr que ça utilise le temps UNIX ;p )
Mais pour XP, le problème c’est surtout les laptops qu’on doit préserver au taf pour la compatibilité avec d’anciens matériels / logiciels (et ne parlez pas de VMs, ça marche bien des fois, mais clairement pas pour tout!)
#10
La seule incompatibilité de Windows 3.1 avec l’an 2000 était le Gestionnaire de fichiers qui affichait « 19:0 » à la place de « 2000 » dans la colonne des dates (au passage, 2022 y serait affiché « 19<2 », puisque ça suit la liste des caractères de la table ANSI : 0-9, puis :, ;, , ?, @…). Mais MS avait filé une version corrigée qui affichait l’année correctement.
Windows (et Windows NT) n’utilisent pas les timestamps UNIX pour calculer le temps. Et leurs plages de dates va du 1/1/1980 au 31/12/2099 (enfin, au moins pour les Windows pas NT).
#11
Merci Microsoft pour la reprise du boulot.
#12
Je voulais dire “des timestamps unix 32 bits” bien entendu
#13
Ben quand tu vois les 3.1 qui tournent encore… 21 ans après la fin du support, je me dit que si ceux là auront sûrement disparus dans 16ans, ce ne sera peut-être pas le cas de tous les XPs (même si à priori pas impactés sur le timestamp d’après @Trit’) et autres joyeusetés 32bits ;)
Tu est sûr de ton coup?
#14
Bien malin celui qui peut dire quel format est utilisé dans tous les endroits du système.
Exemples:
#15
Merci la frayeur du week-end … et merci la recherche Google.
Une demi-journée à patcher les clients … mais ouf, plus de peur que de mal.
[Mode Ironie ON]
J’espère que la puce Bluetooth implantée avec mon vaccin Covid n’aura pas de bug de date :)
[Mode Ironie OFF]
#16
Il ne suffira pas d’avoir un OS 64 bits pour ne pas avoir le bug malheureusement. Tout programme peut avoir choisi librement de stocker un timestamp dans un entier de 32 bits signé, ça va caster les valeurs pour rentrer dedans et tomber sur d’autres dates. Oui, ça va bien planter une fois qu’on va dépasser la limite en 2038 même sur un OS 64 bits.
C’est pas trivial d’être sûr qu’aucune partie de code n’utilise 32 bits à un moment donné.
Par exemple, il faut tenir compte des différences de comportement entre compilateurs. Tu pourrais vouloir stocker tes timestamps dans des ‘long’ parce que tu as lu la doc de GCC et que les long utilisent 64bits sur les architectures 64bits et tu penses que tu es bon. Or sous Windows, pas de chance, mais les long font 32 bits quelque soit l’architecture. C’est d’ailleurs le cas pour la news actuelle, la date est stockée en BCD dans un long. Tu peux avoir un OS 64 bits, t’étais cuit tout pareil.
Tu peux ajouter à cela tous les legacy codes qui tournent encore dans les milieux bancaires, hospitalier, ou du code propriétaire dont tu dépends directement ou indirectement, qui sont là depuis un bail, que personne n’ose toucher et je pense que tu sues un peu quand on va passer le cap de l’année 2038 ^^’
Regarde rien que pour la faille Log4J, à quel point les sociétés ont du mal à déterminer s’ils ont ou non cette dépendances dans un de leur système et d’en faire une liste exhaustive. Imagine ça pour le stockage de timestamp qui doit être bien plus présent dans pleins de parties du code…
Ca va être joli, ça va planter sévère les jours qui suivent, et on nous dira “m’enfin, on m’avais dit qu’il suffisait de remplacer la machine par du 64 bits”.
#16.1
Oui, et on a déjà eu des exemples en pratique comme Windows Vista, il suffisait d’installer le système en 2099 (n’importe quelle date au delà de 2038, mais il était connu comme le 2099 trick) et cela servait de bypass pour pouvoir le re-arm sans fin. Il n’y avait d’ailleurs que la partie driver qui posait un soucis pour les version 64bits, car la partie gestion de l’activation était côté en 32bits même pour les systèmes 64bits.
Comme quoi, la fin d’année 2038 va être compliquée vu les kilos d’applications 32bits qui flottent partout.
#16.2
Soyons sérieux, si tu veux 64 bits, tu utilises uint64_t et pas long, ou alors t’es vraiment un mauvais programmeur.
#16.3
Je ne te parle pas spécifiquement du code que tu écris en étant conscient du problème. Bien sûr que là, tu vas utiliser des entiers de taille fixe. Je n’ai pas du tout dit qu’il fallait stocker un timestamp dans un long. Je parlais d’une hypothèse où un développeur pouvait supposer qu’un long ait la taille nécessaire.
Ce développeur ayant codé une petite fonction innocente dans l’une des libs que tu utilises, paf, malgré tes bonnes pratiques, tu seras dans le jus comme tout le monde :P
Peux-tu être sûr que tout le code que tu utilises aies suivi cette bonne pratique ?
C’est là que le problème existe. Je réagit juste au fait que non, il ne suffit pas de compiler en 64 bits pour corriger automatiquement les problèmes potentiels, c’est un peu plus subtil que ça.
#17
Ou avant pour certains systèmes faisant des calculs prévisionnels sur 20 ans et qui ont déjà planté il y a un peu moins de 2 ans.
#18
#19
maximale de 2 147 483 647
J’ai aussi une application php qui a buggé suite au passage en 2022 car elle stockait les numéros de commande dans une colonne dans une table de la bdd en entier signé. Ils utilisaient les deux 1ers chiffres correspondant à l’année de la commande :
21 xx xxx xxx. Et ben en 2022 erreur fatale, il veut enregistrer un 22 xx xxx xxx dans une colonne qui n’accepte pas plus que 21 47 483 647
J’ai du changer les colonnes concernées en non-signée
#20
Encore une fois bravo Microsoft pour la démonstration de l’excellence de leur ingénierie logicielle.
Enfin, ne leur jetons pas la pierre, ce n’est pas comme si le problème était largement prévisible, comme si on parlait d’un outil entièrement édité par eux, ou comme s’ils disposaient de dizaines de milliards de bénéfices par ans pour renforcer les équipes de dev / test automatisé / test manuel…
Oh wait!
T’as dû vachement vite dessoûler avec un pareil ascendeur émotionnel
#21
Quand on a besoin d’une date, on utilise un champ ou type date fourni par une librairie ou l’outil (donc à priori débogué) et on ne convertit pas dans autre chose.
Parce que y a pas que le stockage, il y a aussi les calculs sur ces dates, et ce n’est pas trivial. J’ai déjà eu à traiter des 30 février à cause d’un bug similaire, ça fait tout drôle quand ça plante.
(Il y a pire : les chaînes dans des champs libres, surtout dans un contexte international où ne sait pas si le 03/02/22 est 2 mars, le 3 février, voire le 22 février 2003).
#22
Vu que je fais de la prog système, oui
Il suffit que ce soit bon dans l’OS pour que je ne sois pas embêté.
Après, ceux qui font du spaghetti php, eux ils sont pas sortis de l’auberge.
#22.1
Haha, mais oui, tous les développeurs systèmes suivent les bonnes pratiques, c’est bien connu ! ^^’
Je suis dev système aussi, je suis assez confiant sur le code que j’écris, mais le business derrière ne dépend pas que de mon code en fait. Pouvoir certifier que toute la stack dont dépend notre plateforme est failproof pour le bug de l’an 2038 c’est un peu fort.
Je dis pas que ça va nécessairement amener à des bugs dramatiques et que ça va impacter tout le monde, mais il ne suffira pas simplement de basculer sur des OS 64 bits où tout est compilé en 64 bits pour que ça passe et ce même si tu fais essentiellement de la programmation système.
Et si c’est la conviction des devs, ben de nombreuses choses vont nécessairement planter vu qu’ils ne feront même pas l’effort de vérifier que leur code est compatible.
Fin soit, ton code tournera sans doute toujours très bien, là n’est pas mon point. Mais pas sûr que la totalité des services dont tu dépend ne vont pas avoir le moindre soucis ;)
#23
Après, il ne faut pas se focaliser que sur les dates… Ou que sur l’OS.
Le problème des dates:
-> Tu arrives à des cas où si tu relis la date en BDD, elle est différente de la date relue de l’OS. Donc il faut systématiquement arrondir à la seconde. Donc opérations en plus à chaque lecture à ne pas oublier.
Sans parler de l’étape de restitution en HTML/Javascript qui a encore un codage et stockage différents…
Les problèmes les plus touchy que je connaisse en informatique de gestion/web:
Les algos, le système, c’est complexe mais facile car “prouvable” (et généralement assez déterministe). Le reste ça paraît simple mais c’est hyper fragile.
#24
Sur un x86, le décodage BCD est cablé depuis le 8086 (d’ailleurs, c’était utile à l’époque, maintenant un peu moins :))