Conversation

Notices

1. GeniusMusing (geniusmusing@nu.federati.net)'s status on Saturday, 01-Jan-2022 19:06:25 EST GeniusMusing
   Microsoft Exchange year 2022 bug in FIP-FS breaks email delivery
   https://nu.federati.net/url/284243
   
   >Microsoft Exchange on-premise servers cannot deliver email starting on January 1st, 2022, due to a "Year 2022" bug in the FIP-FS anti-malware scanning engine.
   >
   >Starting with Exchange Server 2013, Microsoft enabled the FIP-FS anti-spam and anti-malware scanning engine by default to protect users from malicious email.
   >...
   
   LOL
   1. lnxw48a1 (lnxw48a1@nu.federati.net)'s status on Saturday, 01-Jan-2022 19:33:34 EST lnxw48a1

      in reply to
      @geniusmusing When I first read this, I thought it was FIPS. https://en.wikipedia.org/wiki/Federal_Information_Processing_Standards
   2. lnxw48a1 (lnxw48a1@nu.federati.net)'s status on Sunday, 02-Jan-2022 06:38:32 EST lnxw48a1

      in reply to
      @geniusmusing
      
      > this is caused by Microsoft using a signed int32 variable to store the value of a date, which has a maximum value of 2,147,483,647
      
      This is basically a Y2K / Y2K32 bug. We’ve known such things could happen since the late 1990s, so I’m really surprised that #Microsoft didn’t use a wider datatype (int64 at least).
      1. Bob Jonkman (bobjonkman@gs.jonkman.ca)'s status on Sunday, 02-Jan-2022 23:11:09 EST Bob Jonkman

         in reply to
         From what I can tell, they were using the decimal digits of the 32-bit number as a sort of BCD, with the base10 digits representing portions of the date. The example used is "the new date value of 2,201,010,001 is over the max value of 'long' int32 being 2,147,483,647". So, YY MMDDHHMM ?
         
         What an extraordinarily stupid way to represent a date.
         1. Alexandre Oliva (lxo@gnusocial.net)'s status on Tuesday, 04-Jan-2022 02:34:39 EST Alexandre Oliva

            in reply to
            what's most incredible about this date representation is that it was introduced after Y2K. it wouldn't have worked up to [19]99
            think about it. someone implemented that after all the many years of preparation and patching decades-old systems for Y2K, knowing (or, worse, without realizing) that it had at most a couple of decades of use. how screwy and irresponsible is that?
            1. Bob Jonkman (bobjonkman@gs.jonkman.ca)'s status on Tuesday, 04-Jan-2022 05:07:25 EST Bob Jonkman

               in reply to
               According The Register's forum, this is the patch: "The current fix: Represent 2022-01-02 as 2021-12-33."
               
               https://forums.theregister.com/forum/all/2022/01/03/exchange_servery2k22_flaw/#c_4389861
               1. Alexandre Oliva (lxo@gnusocial.net)'s status on Tuesday, 04-Jan-2022 07:33:28 EST Alexandre Oliva

                  in reply to
                  one would hope that's just a quick patch to get it going while they implement a proper fix, but who knows?
                  1. GeniusMusing (geniusmusing@nu.federati.net)'s status on Tuesday, 04-Jan-2022 16:49:41 EST GeniusMusing

                     in reply to
                     @lnxw48a1 @lxo @bobjonkman
                     From Security Now pdf show notes.
                     https://www.grc.com/sn/SN-852-Notes.pdf
                     
                     snip
                     
                     >And how did Microsoft fix this so quickly, when most things Microsoft does takes months or sometimes even years? Ahhhh... they punted: Microsoft released a PowerShell-based script called “Reset-ScanEngineVersion.ps1” which needed to be run on each Exchange mailbox server used for downloading antimalware updates. What does the little PowerShell script do? It adjusts
                     the date back to 21 12 33 0001.
                     >
                     >Yes, that’s right. In Redmond, New Years has been delayed... and December has 33 days.
                     
                     snip
               2. clacke: inhibited exhausted pixie dream boy 🇸🇪🇭🇰💙💛 (clacke@libranet.de)'s status on Monday, 24-Jan-2022 22:52:59 EST clacke: inhibited exhausted pixie dream boy 🇸🇪🇭🇰💙💛

                  in reply to
                  @Bob Jonkman Why not represent it as 2020-25-02 🤣
      2. lnxw48a1 (lnxw48a1@nu.federati.net)'s status on Monday, 03-Jan-2022 08:05:14 EST lnxw48a1

         in reply to
         Make that Y2K38.
   3. lnxw48a1 (lnxw48a1@nu.federati.net)'s status on Monday, 03-Jan-2022 21:20:42 EST lnxw48a1

      in reply to
      @geniusmusing @bobjonkman
      
      #Microsoft has patched the Y2K-alike bug in #Exchange. https://www.theregister.com/2022/01/03/exchange_servery2k22_flaw/