Journal Le bug de l'an 2000 a 22 ans !

Posté par  . Licence CC By‑SA.
Étiquettes :
24
6
jan.
2022

Bonjour Nal,

Une petite blague pour l'année 2022 qui ne t'a pas encore été compté (mouarf).
Il se trouve que certain développeurs ont stocké la date dans des entiers signés en 32bits sous la forme : YYMMDDhhmm. Vous l'avez ? Le plus grand entier stockable est 2147483647 et la date du 1er janvier 2022 est : 2201010000.

Paf, pastèque !

Le plus connu se trouve dans Exchange mais ce n'est pas le seul. Je te laisse faire le tour de la toile avec le doux nom du dit bug : y2k22.

Bonne journée.

  • # Le lien arstechnica

    Posté par  . Évalué à 4.

    https://arstechnica.com/information-technology/2022/01/exchange-server-bug-gets-a-fix-after-ruining-admins-new-years-plans/

  • # Pas la date

    Posté par  (site web personnel) . Évalué à 5.

    Ce n'est pas la date mais le numéro de version, qui à ce format basé sur la date. Le fix consiste à patcher le numéro de version de la mise à jour pour la faire commencer par 21.

    Ce que je trouve fou c'est d'avoir publié une mise à jour pour le jour de l'an. Et visiblement pas beaucoup testée…

    • [^] # Re: Pas la date

      Posté par  (site web personnel) . Évalué à 1.

      Ce que je trouve fou c'est d'avoir publié une mise à jour pour le jour de l'an.

      Ben… le bug ayant été vu le jour de l'an, c'est assez normal…

      Et visiblement pas beaucoup testée…

      Ils n'ont pas eu beaucoup de temps.

      • [^] # Re: Pas la date

        Posté par  . Évalué à 4. Dernière modification le 06 janvier 2022 à 16:21.

        Si je comprends bien, le bug est causé par une mise à jour qui a été faite le jour de l'an (avant que le bug soit découvert), et dont le numéro de version (22…) a révélé le bug.

        Cela a entraîné ensuite une deuxième mise à jour corrective avec un numéro de version… plus petit, ne provoquant donc plus le bug. (C'est une rustine qui corrige le symptôme mais pas le problème, j'imagine pour se donner le temps de le corriger proprement avec moins de stress.)

        • [^] # Re: Pas la date

          Posté par  . Évalué à 9.

          Cela a entraîné ensuite une deuxième mise à jour corrective avec un numéro de version… plus petit, ne provoquant donc plus le bug.

          2112330001

          Le 33 décembre 2021 leur gestion de la date a l'air nickel :p

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Pas la date

            Posté par  . Évalué à 3.

            Le seul mec dispo le 1er janvier était un dev php, faut pas (trop) lui en vouloir.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: Pas la date

              Posté par  . Évalué à 2.

              D'autant que j'imagine que la version précédente n'était pas 2112312359

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Pas la date

        Posté par  . Évalué à 10.

        Ils n'ont pas eu beaucoup de temps.

        De ce que je vois c'est une vérification qui est faite au démarrage du service. Je me demande s'ils ont même exécuté le binaire final ailleurs que chez leur client.

        Ça relativise quand un ancien de chez Microsoft expliquent qu'ils ne sortent pas des patchs à l'arrache et font des tests significatifs.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Pas la date

          Posté par  (Mastodon) . Évalué à 4.

          En l'occurence ce n'est pas un patch mais une base de définitions de malware. Donc je peux très bien imaginer un meeting avec un manager dire à un moment donné "on est toujours en retard face aux concurrents X, Y, on doit livrer les bases de définitions plus vite". Et un ingénieur de dire "on fait des tests pour chaque base de définitions mais depuis qu'on fait ces tests on n'a jamais vu une seul erreur et il n'y a aucune raison parce que ce n'est pas du code, on peut peut-être les supprimer pour livrer plus vite".

          Et pouf on vire les tests.

          La question après reste de l'impact:
          - est-ce que l'image de marque de exchange a souffert au point qu'une seule entreprise va dire j'en ai marre, je migre sur autre chose ? Sachant que sortir d'exchange (comme sortir d'autres truc comme Lotus Notes ou Groupwise) ce n'est pas du tout facile et c'est le genre de gros projet que toute le monde préferrerait laisser à son successeur. Au pire ça a du donner l'envie à certains admins de migrer d'un exchange on-prem vers office365 pour ne pas avoir à bosser le 1er janvier et laisser Microsoft résoudre son problème tout seul.
          - est-ce que ça a coûté cher aux clients? Il n'y a il me semble pas eu de perte de donnée puisque l'email est asynchrone et que la plupart des serveurs de mails essayent de renvoyer pendant 2 à 4 jours. En terme de disruption de flux de travail le 1er janvier pas grand monde bosse. Ça a du faire chier des admins qui étaient de piquets et des organisations qui bossent 24/24 (services hospitaliers, etc) mais ceux-ci n'utilisent pas en général l'email et les public folders pour des urgences donc ça n'a pas du être très dérangeant.

          Donc passé le momen cocasse de se dire "ha ha ha une date en int32 les n00bs!" l'impact n'est pas si grand. Du coup doit-on dans ce cas rajouter ce test à chaque sortie de baseline ou simplement produire le patch, tester sur des numéros de versions prévues pour ces 30 prochaines années et ajouter un commentaire dans la doc interne que si on change ce code ou la nomemclature de version il faut retester?

          • [^] # Re: Pas la date

            Posté par  . Évalué à 5.

            Donc passé le momen cocasse de se dire "ha ha ha une date en int32 les n00bs!" l'impact n'est pas si grand. Du coup doit-on dans ce cas rajouter ce test à chaque sortie de baseline ou simplement produire le patch, tester sur des numéros de versions prévues pour ces 30 prochaines années et ajouter un commentaire dans la doc interne que si on change ce code ou la nomemclature de version il faut retester?

            Ça dépend de la qualité que tu cherche à produire.

            Vraiment. On écrit tous des bugs et personne ne peut dire que ça peut ne pas exister, mais la manière que tu as de gérer les bugs d'assurer qu'ils en arrivent moins va changer l'image de ce que tu produit. Pas la première fois, ni même la seconde fois, mais ça devient une culture d'entreprise et ça peut mal finir. Boeing s'est tapé en moins de 2 ans un gros problème sur son 737 MAX entre autre à cause du logiciel et la même pour un module qu'ils ont produit pour la NASA et où la NASA leur a dit qu'ils allaient eux-même revoir tout le code.

            Et l'excuse consistant à se cacher derrière le marketing, le manager ou autre, ça va 3 minutes. Ils ne connaissent pas ton métier, c'est normal c'est pas le leur. Donc c'est à toi d'expliquer ce qui peut et ce qui ne peux pas se faire.

            Je ne dis pas que MS applique le comportement que tu décrit. Je n'en sais strictement rien.

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Pas la date

      Posté par  . Évalué à 4. Dernière modification le 06 janvier 2022 à 17:54.

      Ce n'est pas la date mais le numéro de version, qui à ce format basé sur la date. Le fix consiste à patcher le numéro de version de la mise à jour pour la faire commencer par 21.

      D'après Microsoft c'est les 2.

      The problem relates to a date check failure with the change of the new year and it not a failure of the AV engine itself.

      source : forum Microsoft

      De ce que je comprends ils encodent dans le numéro de version la date et s'en servent pour savoir s'il faut faire une mise à jour.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Pas la date

        Posté par  . Évalué à 4.

        Et si je comprends bien, ce n'est pas un patch du 1er janvier à l'origine du problème, c'est le fichier de signature généré automatiquement tous les jours qui ce numéro de version.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Pas la date

          Posté par  . Évalué à 2.

          Et si je comprends bien, ce n'est pas un patch du 1er janvier à l'origine du problème, c'est le fichier de signature généré automatiquement tous les jours qui ce numéro de version.

          J'en doute, mais je n'arrive pas à en savoir vraiment plus (internet est spamé d'info peu pointue). Si on regarde la solution indiquée par MS, c'est vraiment la version qu'ils ont publiée qui a le problème. Ce que je comprends c'est qu'ils mettent à jour ensemble le moteur et un fichier signature qui va avec et que le moteur vérifie la signature (je ne sais pas s'il s'agit d'une signature cryptographique ou d'une liste de signatures qu'il tente de chercher dans les mails).

          Si c'était un processus automatique qui produit ce fichier régulièrement en fonction de la date courante toutes les versions seraient impactées.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Pas la date

            Posté par  . Évalué à 4.

            Ce que je comprends c'est qu'ils mettent à jour ensemble le moteur et un fichier signature qui va avec et que le moteur vérifie la signature (je ne sais pas s'il s'agit d'une signature cryptographique ou d'une liste de signatures qu'il tente de chercher dans les mails).

            Même si c'est ça, rien ne dit que le moteur a été mis à jour, ça peut être simplement le fichier de signature si les deux sont publiés ensemble.

            Si c'était un processus automatique qui produit ce fichier régulièrement en fonction de la date courante toutes les versions seraient impactées.

            Quelles version ne sont pas impactées ? D'après ton lien, ça parle de "Exchange Server 2016 and Exchange Server 2019", ça ne dit pas qu'il y a des exceptions.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Pas la date

              Posté par  . Évalué à 2.

              Même si c'est ça, rien ne dit que le moteur a été mis à jour, ça peut être simplement le fichier de signature si les deux sont publiés ensemble.

              Ils demandent de supprimer le moteur. Ils ont publié une nouvelle version de ce dernier sachant qu'ils ont des numéros de versions distincts.

              EngineVersion         : 1.1.18800.4
SignatureVersion      : 1.355.1227.0

              Quelles version ne sont pas impactées ? D'après ton lien, ça parle de "Exchange Server 2016 and Exchange Server 2019", ça ne dit pas qu'il y a des exceptions.

              Il n'y a qu'une seule version d'impacter. La première étape du fixe c'est de vérifier que tu as installé la version problématique.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: Pas la date

                Posté par  . Évalué à 5.

                Run Get-EngineUpdateInformation and check the UpdateVersion information. If it starts with "22…" then proceed. If the installed version starts with "21…" you do not need to take action.

                Ça ne donne pas un numéro de version précis problématique.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Pas la date

                  Posté par  . Évalué à 2.

                  Je comprends pas ce que tu veux dire.

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # pas grave

    Posté par  (site web personnel, Mastodon) . Évalué à 6.

    je me souviens au boulot on avait des systèmes qui passaient pas l'an 2000, pas grave on a remonté les horloges de 10 ans dans le temps et le tour était joué :-)

    https://www.funix.org mettez un manchot dans votre PC

  • # Pfff oh les cons... euh ça arrive

    Posté par  . Évalué à 10. Dernière modification le 06 janvier 2022 à 21:04.

    (1) Oh les cons j'ai pensé en lisant mes flux RSS hier matin en tombant sur cette actu.

    J'ai aussitôt envoyé un mail private joke à mon sysadmin qui m'a confirmé que : de la même manière que nous étions immunisés de log4shell grâce à notre politique de non mise à jour sécurité, ce bug de l'an 2022 ne concernait pas notre increvable Exchange 2007.

    Quelques minutes plus tard, serilog (dotnet #1) me remonte des erreurs de retour de paiement d'un de nos sites de vente : "arithmetic overflow" sur OrderId. Après analyse en db : ce numéro de facture est généré sous la forme "YYMMDDxxxxx" et stocké dans un int32…

    (1) euh ça arrive à tout le monde #metoo

  • # Paf coup de vieux

    Posté par  . Évalué à 1.

    22 ans.. P€ ¢ © ® 22 ans..

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.