By Alexandre Siviero, Atila Altoé and Laura Cardillo
As soon as 2022 began, a problem in the component for scanning attachments to mail on Exchange servers disrupted the messaging queues. One interesting point was the similarity of the programming flaw to the millennium bug. This is why it earned the nickname Y2K22.
Introduction
For Exchange server administrators, the start of 2022 brought back memories of the millennium bug. An error message in the mail attachment scanning component interrupted all sending and receiving of messages as soon as the new year began. Because of this similarity, the flaw that caused this outage was informally dubbed Y2K22 (year two thousand and twenty two, 2022), alluding to the English term for the millennium bug - Y2K (year two thousand, 2000).
Initial response to failure
As soon as 2022 began, administrators of environments with the on premises Exchange framework noticed that the queues for sending and receiving email stopped altogether. Reddit and Twitter concentrated researchers looking for a technical explanation.
An error message was the common thread among the affected environments:
Description: The FIP-FS "Microsoft" Scan Engine failed to load. PID: 23092, Error Code: 0x80004005. Error Description: Can't convert "2201010001" to long.
2201010001 is the version number that was assigned to the latest update of Microsoft's Filtering Engine. Both this and previous version numbers follow the year/month/day pattern in their composition, i.e. 220101 is equivalent to a version dated January 1st, 2022.
The term long is a data type used by Microsoft. It is a variable that receives integers (with or without sign) up to 32 bits in size.
Maximum value in a long
To establish which is the largest possible number that can be written with 32 bits it is necessary to use binary notation. Each bit is a unit value that contains the numbers 0 or 1. Thirty-two one numbers, when converted to decimal notation, equals 4,294,967,295.
1111 1111 1111 1111 1111 1111 1111 1111
4,294,967,295 in binary notation
It is possible to store both positive and negative numbers, which is called signed long. In this case the last bit is used to store the sign: 0 means positive and 1 means negative. With one bit less to store the number itself, the largest possible value is +2,147,483,647, while the smallest value is -2,147,483,647.
0111 1111 1111 1111 1111 1111 1111 1111
+2,147,483,647 in binary notation
Technical Analysis
Going back to the problematic version number of the Exchange attachment scanning tool, 2201010001. Separating the thousands, we have the number 2.201.010.001. According to the error message, this value cannot be converted into a long variable because the maximum value of a signed long is +2,147,483,647. Here is the similarity to the millennium bug : by using the last two digits of 2022 in the version number, Microsoft created an incompatible situation with a software code, causing an error that stopped all mail queues of the on premise Exchange frameworks.
Mitigation
On January 3rd, Microsoft released a fix for this flaw. There has been no change in the code to support values above the maximum of a signed long; it changed the version number to 2112330001, returning to supported values in 32 bit with sign. This change can be made manually or via powershell script . Both methods are available in a Microsoft release, applicable only for Exchange Server 2016 and 2019, where the structure for sending and receiving email is local(on premise).
Bibliography
https://www.reddit.com/r/sysadmin/comments/rt91z6/exchange_2019_antimalware_bad_update/
https://www.fudzilla.com/news/54133-year-2022-bug-hits-microsoft-exchange
https://docs.microsoft.com/en-us/dotnet/api/system.int32?view=net-6.0
https://twitter.com/JRoosen/status/1477203087421018118?ref_src=twsrc%5Etfw