照这样下去,“千年虫”还得再来十遍

在 21 年前世纪之交, 全球的计算机系统和互联网曾经出过一个重大事件:千年虫 。

照这样下去,“千年虫”还得再来十遍

文章插图
” 这玩意儿是怎么发布出来的?而且还是在新年夜???”
照这样下去,“千年虫”还得再来十遍

文章插图
” 电话都被打爆了 。 微软你弄啥嘞?”
问题, 出在微软推送的这次更新的版本号上 。
这次的更新, 里面包含的电子邮件恶意软件扫描引擎的版本号是 2201010001, 表示的是 2022年01月01日00点01分 。
微软的产品和系统在表示时间的时候, 用的都是这种符号整数 。 然而, 根据微软自己的开发文档, 其系统能够接受的 Int32 符号整数的最大值是 2147483647 。
这个最大值的前两位是21 。
也就是说, 采用这种整数方式来记录和表示时间, 只能够正常覆盖到 2021 年的最后一秒 。
所以, 当微软推送出这个 2201010001 版本的时候, 版本数字超过了系统能够接受的整数最大值, 结果就直接把 Exchange Server 邮件系统给搞崩溃了……
目前, 微软方面已经提供了修复此问题的方法, 可以执行 PowerShell 脚本来自动修复, 也可以用手动方法修复 。 修复必须在所有被波及的 Exchange Server 2016 或 2019 版本服务器上执行 。
很多被影响到的公司 IT, 在修复过程中也遇到了各种各样的问题 。 总的来说, 这次微软送的这个新年大礼包, 让大家整个新年都没过好……
【照这样下去,“千年虫”还得再来十遍】在微软官方技术论坛上, 一位用户发出了灵魂拷问:谁会在 12 月 31 日推送生产环境更新啊?

照这样下去,“千年虫”还得再来十遍

文章插图
千年虫重演, 原因依然很蠢

这次微软邮件服务器的 bug, 以及其它公司 / 产品发生的类似的日期时间处理错误, 一起被命名为 Y2K22(也即 Year 2022 的缩写) 。
为什么这样命名?正是因为, 导致这些 bug 出现的问题, 和 21 年前的千年虫 ( Y2K bug ) , 几乎一模一样 。
文章开始提到, 千年虫的出现, 是因为当时一些相对比较古老的计算机系统, 在处理年份的时候会采用两位数简写 。
当时的普通人压根想不到, 新千年的到来会让计算机系统出故障——唯一有可能预知这种情况发生的, 也就只有程序员了 。
而当千年虫事件即将发生的时候, 那些已经投入使用十年甚至 20 年的系统, 背后的 COBOL 程序员(大多已经或者快要退休了), 又被请出山来修复他们当年 ” 埋 ” 下的这些漏洞……
在当时, 有两种修复的思路:
1)全盘重写所有系统的代码, 称为 “expansion”;
2)打个快速的补丁, 让计算机能够将从 00 到 20 的数字, 正确识别为 2000 年到 2020 年——这种方式也被称为 “windowing”.
具体来说, 这个补丁让计算机系统将 1970 年 1 月 1 日 0 时 0 秒(也即程序员都非常熟悉的 Unix 时间戳)作为百年 ” 时间窗口 ” 的中间点, 也即从 1920 年到 2020 年的任何一个时间点, 在计算机系统里都可采用其到 Unix 时间戳的距离作为表示方法 。
” 高性能计算机新闻网 ” 的一篇发布于 1999 年的报道显示, 在当时, 大约有八成的系统最后都是用第二种快速补丁的方式修复的 。 相比一劳永逸的全盘重写, 快速补丁的方式的成本优势非常明显, 然而即便如此, 全世界的预估修复成本加起来也高达 3000 亿美元……
照这样下去,“千年虫”还得再来十遍


特别声明:本站内容均来自网友提供或互联网,仅供参考,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。