Unix这颗大雷,真的会让全球电子设备瘫痪吗?
2024-1-1 09:32:6 Author: FreeBuf(查看原文) 阅读量:8 收藏

左右滑动查看更多

新年伊始,万象更新,今天不发那些网络安全新闻,聊聊轻松点的话题,给大家在元旦假期里解解闷。比如业内一直盛传的Unix时间的雷,真的会让全球电子设备瘫痪吗?

昨天,几个安全圈好友聚在一起喝酒,不知怎么就聊到了“千年虫”的问题。当年开发计算机操作系统的那帮大神们亲手埋下的雷,在时间的流逝下慢慢爆出了各种匪夷所思的安全BUG。千禧年是Y2K的雷,而Unix的雷则是在2038年爆发。

Unix的雷是怎么埋下的

话说在1969年,贝尔实验室的大神Ken Thompson曾利用老婆回娘家的假期,开发了一个操作系统,它叫Unix。没错,就是咱们现在使用的那个Unix,开发它大概用了三周(夸张)。看来,老婆回娘家可以大幅提升已婚男人创造力,在全球都是统一的。

在开发过程中,他遇到了一个严重的问题:如何在Unix中表示日期和时间?最简单的办法是用一个字符串来表示,例如1970-09-17 00:00:30.751,但这明显是一个看起来比较复杂的办法。最后Ken决定用一个整数来表示日期和时间,也就是Unix 纪元时间,并将1970年1月1日00:00:00设定为开始时间。

所以Unix 系统的时间计算方法其实是用秒数来表示系统时间。换句话说当下的时间(2024年1月1日00:00:00)是从1970年1月1日00:00:00走过多少秒的时间,即系统时间 = 基准时间+秒数。感兴趣的朋友,可以访问time.is/Unix网站,可以知道从1970年1月1日00:00:00到现在一共过去了多少秒。

由于Ken将Unix时间确定为32位整数,这就导致一个很严重的系统BUG,32位的有符号整数最大值是2147483647(距离1970年1月1日00:00:00走过了2147483647秒),简单换算下Unix时间为2038年1月19号 03:14:07 UTC,再往后就没了。

一旦越过这个时间最大值,Unix系统时间将会在内部被表示为一个负数,并造成程序无法工作,因为它们无法将此时间识别为 2038 年,甚至还有可能调回到 1970 年。这让很多人想起了千禧年的“千年虫(Y2K)”事件,因此Unix系统时间问题也被称为Y2K38。

当然这也不能完全怪Ken。毕竟那时候主流计算机还都是使用16位,所以使用32位整数来设定时间已经够够的了。在他看来,Unix系统能不能活到2000年都是个问题,更别提2038年。但谁能想到,Unix系统竟是如此的强悍,不仅可以和Windows相抗衡,还统治了服务器端的OS市场,在计算机操作系统的发展史上占有重要的地位,此后“简洁,一致性,易使用”被很多开发人员奉为圭臬。

问题很严重吗?

扯远了。。

其实解决方案也不复杂,将32 位有符号整数修改成 64 位有符号整数(时间长度近300亿)。目前Linux内核开始全面支持64位时间戳的系统调用,记得在升级之后看看原来的程序和库是否使用32位编译,如果是则需改成64位,否则依然会产生溢出问题。

虽然很多文章将这一问题描述地很严重,甚至会导致大部分电脑瘫痪无法工作。但我们认为,这样的情况并不会出现。距离2038年还有整整14年的时间,以现在电子设备迭代的速度来看,那时候还有没有32位的电脑都是个未知数。

其次,从千年虫事件来看,最终结果没有产生非常严重的影响,部分安全问题都控制在小范围内,尤其是并且对现实世界产生严重影响,相信Y2K38也不会有太过严重的后果。目前Unix对这一BUG也是心知肚明,不可能找不到一个妥善的解决办法,所以大家完全不用担心。

最后祝所有FreeBuf粉丝与用户元旦快乐!!!

*资源来源于互联网

FreeBuf粉丝交流群招新啦!
在这里,拓宽网安边界
甲方安全建设干货;
乙方最新技术理念;
全球最新的网络安全资讯;
群内不定期开启各种抽奖活动;
FreeBuf盲盒、大象公仔......
扫码添加小蜜蜂微信回复“加群”,申请加入群聊


文章来源: http://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651253347&idx=1&sn=f159ba8a942cb5c5fd601a5cdec9e6a8&chksm=bccedef500870a93e148e07f2ee40eff0be051a5f5c46a61cb45d2e0489d17746775212d3490&scene=0&xtrack=1#rd
如有侵权请联系:admin#unsafe.sh