微軟2022年第一號bug讓大量程序員連夜加班 只因日期數據溢出

沒想到,2022年的到來,也給微軟帶來了一個新bug隨着日期從2021年12月31日跳轉到2022年1月1日,不少使用微軟Exchange的公司發現,自己寫好的新年祝福等郵件,突然發不出去了。

Exchange Server是微軟推出的一套電子郵件服務組件,可用於構建企業、高校或機構的郵件系統。簡單來說,用它不止能構建“郵箱工作群”,還能協調內部工作流等。

這些公司的郵箱服務器內滯留了大量郵件,有些甚至達到數十萬封,面臨服務器存儲不下的問題。

目前這個bug已經在Reddit熱度上千,許多人表示“年都沒跨好就在這修bug”:

微軟2022年第一號bug讓大量程序員連夜加班 只因日期數據溢出

新年(嗶)快樂!

微軟2022年第一號bug讓大量程序員連夜加班 只因日期數據溢出

我本來還在度假呢,就給我拉回來處理這個玩意了……

微軟2022年第一號bug讓大量程序員連夜加班 只因日期數據溢出

所以到底是怎麼回事?

微軟2022版“千年蟲”

據一位Exchange管理員Joseph Roosen表示,這是一個由於“2022年”的到來而導致的bug。

這個bug的根源,是微軟Exchange上面的郵件過濾管理系統(FIP-FS),採用了一種名叫“yymmddHHMM”的有符號變量(Int32,也就是long)來存儲日期。

微軟2022年第一號bug讓大量程序員連夜加班 只因日期數據溢出

其中,yymmddHHMM分別指代用兩位來存儲年(years)、月(months)、日(days)、小時(Hours)、分鐘(Minutes)。

這個數據類型存在一個問題:

有符號的Int32最多只能存儲-2147483647到+2147483647的數據。

然而,從2022年1月1日0時開始,“yymmddHHMM”的yy就已經變成了“22”,超過了Int32所能存儲的數據最大範圍:

2147483647

22XXXXXXX

於是,在2022年1月1日這天,所有用Exchange服務器發郵件的公司,都收到了這樣一條錯誤提醒:

The FIP-FS Scan Process failed initialization. Error: 0x8004005. Error Details: Unspecified Error” or “Error Code: 0x80004005. Error Description: Can’t convert “2201010001” to long.(FIP-FS掃描處理初始化失敗……無法將“2201010001”轉變為long數據類型)

它最初被一位名叫@miketheitguy的推特用戶發現:

微軟2022年第一號bug讓大量程序員連夜加班 只因日期數據溢出

由於和“千年蟲”一樣都是日期給計算機帶來的bug,這次bug也被一些Exchange管理員命名為Y2K22。

其中,Y2K指的是著名的“千年蟲”問題,由於部分計算機程序只採用兩位十進制數表示年份,在跨世紀時就會出現錯誤的結果;22指的則是2022年。

這個bug在不少Exchange Server版本中都出現了相同的問題,包括2016和2019等。

微軟2022年第一號bug讓大量程序員連夜加班 只因日期數據溢出

目前,微軟的Exchange團隊正在緊急修復中。

他們表示,幾天後會發布一個Exchange Server更新,裡面將用一個更大的變量類型來保存日期。

微軟2022年第一號bug讓大量程序員連夜加班 只因日期數據溢出

然而在這之前,使用Exchange Server的公司們必須想辦法把郵件發出去。

一些權宜之計

微軟團隊表示,如果有非常緊急的郵件需要發送,需要先關掉Exchange中的FIP-FS功能。

這是個Exchange上的垃圾郵件過濾器,平時會用來掃描郵件中自帶的惡意軟件、或是垃圾郵件。

目前微軟官方也提供了一些禁用或繞過惡意軟件掃描的方法。

然而,這樣操作的後果是公司郵箱“可能收到更多垃圾郵件”。

對此有網友調侃,如果微軟在修復中把有符號變量改成無符號變量,那麼數據的表示範圍就會變成0~4294967295,Exchange郵箱又可以用到2043年了。

微軟2022年第一號bug讓大量程序員連夜加班 只因日期數據溢出

除此之外,目前Reddit網友還給出了一些其他的解決方案。

例如,有網友發布了一個非官方的自定義腳本,可以將日期回滾到2021年,但他對此表示,一切風險需要使用者自己承擔。

如果還沒想好怎麼解決你的Exchange郵箱系統問題,可以先用上面這些方法試一試。

(0)
上一篇 2022-01-02 21:16
下一篇 2022-01-02 21:17

相关推荐