Discussion :

[Bruno]

Microsoft corrige le bogue de l'an 2022 qui a perturbé le courrier électronique dans le monde entier,
une erreur qui empêchait les serveurs de prendre en compte l'année 2022

le 1er janvier 2022 à 0 h 00, les serveurs de la messagerie Exchange ont bloqué l'envoi de mails. Microsoft a publié un correctif pour ce bogue d'Exchange Server qui a interrompu la distribution du courrier sur site dans le monde entier au moment où les horloges sonnaient la nouvelle année. La perturbation massive est due à une défaillance de la vérification de la date dans Exchange Server 2016 et 2019, qui empêchait les serveurs de prendre en compte l'année 2022, ce qui a incité certains à l'appeler le bogue de l'an 2022.

« Nous avons résolu le problème provoquant le blocage des messages dans les files d'attente de transport d'Exchange Server 2016 et Exchange Server 2019 sur site. Le problème est lié à un échec de la vérification de la date avec le changement de la nouvelle année et ce n'est pas une défaillance du moteur AV lui-même. Il ne s'agit pas d'un problème lié à la recherche de logiciels malveillants ou au moteur de logiciels malveillants, ni d'un problème lié à la sécurité. La vérification de la version effectuée par rapport au fichier de signature fait planter le moteur de logiciels malveillants, ce qui a pour effet de bloquer les messages dans les files d'attente », a déclaré Microsoft.

Les programmes de messagerie stockaient les dates et les heures sous forme d'entiers signés, dont le maximum est 2147483647, soit 231-1. Microsoft utilise les deux premiers chiffres d'une version de mise à jour pour indiquer l'année de sa sortie. Tant que l'année était 2021 ou antérieure, tout fonctionnait bien.

Cependant, lorsque Microsoft a publié la version 2201010001 le soir du Nouvel An, les serveurs sur site ont planté parce qu'ils ne pouvaient pas interpréter la date. En conséquence, les messages sont restés bloqués dans les files d'attente de transport. Les administrateurs du monde entier se sont retrouvés à essayer frénétiquement de résoudre le problème au lieu de fêter la nouvelle année avec leurs amis et leur famille.

Le jour suivant, Microsoft a publié un correctif. Il se présente sous deux formes : un script PowerShell automatisé, ou une solution manuelle dans le cas où le script n'a pas fonctionné correctement, comme l'ont signalé certains admins. Dans les deux cas, les corrections doivent être effectuées sur chaque serveur Exchange 2016 et Exchange 2019 sur site à l'intérieur d'une organisation affectée. Le script automatisé peut s'exécuter sur plusieurs serveurs en parallèle. Le fabricant de logiciels a déclaré que le script automatisé « pourrait prendre un certain temps pour s'exécuter » et a exhorté les admins à être patients.

La vérification de la date et de l'heure a été effectuée lorsqu'Exchange a vérifié la version du FIP-FS, un moteur d'analyse qui fait partie des protections antimalware d'Exchange. Lorsque les versions de FIP-FS commençaient par le chiffre 22, la vérification ne pouvait pas être effectuée, et la distribution du courrier était brusquement interrompue. Le correctif arrête les services Microsoft Filtering Management et Microsoft Exchange Transport, supprime les fichiers du moteur AV actuel, puis installe et démarre un moteur AV corrigé.

Microsoft a maintenant créé une solution pour résoudre le problème des messages bloqués dans les files d'attente de transport sur Exchange Server 2016 et Exchange Server 2019 en raison d'un problème de date latente dans un fichier de signature utilisé par le moteur de recherche de logiciels malveillants au sein d'Exchange Server. Une action de l’utilisateur est nécessaire pour mettre en œuvre cette solution. Lorsque le problème se produit, des erreurs dans le journal des événements de l'application sur le serveur Exchange sont visible, plus précisément les événements 5300 et 1106 (FIPFS), comme illustré ci-dessous :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Log Name: Application 
Source: FIPFS 
Logged: 1/1/2022 1:03:42 AM 
Event ID: 5300 
Level: Error 
Computer: server1.contoso.com
Description: The FIP-FS "Microsoft" Scan Engine failed to load. PID: 23092, Error Code: 0x80004005. Error Description: Can't convert "2201010001" to long.
Log Name: Application 
Source: FIPFS 
Logged: 1/1/2022 11:47:16 AM 
Event ID: 1106 
Level: Error 
Computer: server1.contoso.com 
Description: The FIP-FS Scan Process failed initialization. Error: 0x80004005. Error Details: Unspecified error.

Pour résoudre manuellement ce problème, il est recommandé d’effectuer les étapes suivantes sur chaque serveur Exchange de l’organisation.

• vérifiez que la version affectée est installée ;
• exécutez Get-EngineUpdateInformation et vérifiez l'information UpdateVersion ;
• si elle commence par "22...", continuez ;
• Supprimer le moteur et les métadonnées existants ;
• mise à jour vers le dernier moteur ;
• vérifiez les informations de mise à jour du moteur.

Source : Microsoft

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Microsoft déploie le chiffrement de bout en bout des appels Teams après quelques mois de tests, mais prévient que des fonctionnalités ne marcheront plus une fois cette option activée

Microsoft publie Windows App SDK 1.0, la première version complète du « Project Reunion », les développeurs tentent de s'y retrouver

Microsoft fait désormais partie du top 10 des supercalculateurs les plus rapides au monde, voyager-EUS2 ne tourne pas sur Windows mais sur la distribution Linux Ubuntu

Conférence Ignite : Microsoft lance Azure Container Apps, un service de conteneur serverless entièrement géré, pour créer et déployer des applications modernes et microservices à grande échelle

[Invité]

Bonsoir,

Quel est votre avis sur le sujet ?

Cela fait penser au bug de 2038 : https://fr.wikipedia.org/wiki/Bug_de_l%27an_2038

C'est quand même fou ce qu'une erreur de date peut générer comme plantage

[air-dex]

Cela fait penser au bug de 2038 : https://fr.wikipedia.org/wiki/Bug_de_l%27an_2038

C'est quand même fou ce qu'une erreur de date peut générer comme plantage

J'ai pensé à ça en venant commenter ici, à la fameuse "apocalypse 32 bits". Les dates sont décidément une valeur sûre en matière de bugs.

[walfrat]

Les dates, c'est aussi utilisé pour les certificats SSL, les authentifications Kerberos, etc etc.

Perso ça m'est arrivé d'avoir mon PC qui n'était plus du tout à la bonne date et j'avais l'air bien con, je pouvais même plus demander de l'aide à Google.

[jbrosset]

C'est quand même fou que des erreurs de ce genre puissent encore se produire.
J'ai appris l'algorithmique en 1981 : logique des instructions et des structures de données.
J'ai fait du génie logiciel, j'ai appris quelques langages bien mieux fichus conceptuellement que les langages d'aujourd'hui...

Et j'ai l'impression qu'on n'a pas appris grand chose en terme de méthodes, depuis, malgré la fantastique évolution technologique.
On se retrouve encore avec des bugs idiots, du code mal fichu alors qu'on a des ordinateur un million de fois plus puissants qu'autrefois.
Je suis très déçu par le non-progrès en ce domaine.