脆弱的卡巴斯基-Y2K问题的二代，即2038问题

脆弱的卡巴斯基 

 Atreex写道，今天看无意中看到了Y2K问题的二代，即2038问题，并无意中找到一种非常容易杀掉著名杀毒软件卡巴斯基进程的方法。 把计算机的系统日期该为2038年1月19日03:14:07以后的任意一个时间，哈哈，著名的卡巴斯基崩溃了！ 这是不是给病毒制造者一个非常容易逃过卡巴斯基查杀的新方法呢？
 

  HTTP://ike.126.com
 

以下评论仅代表发表者个人观点。

脆弱的卡巴斯基
LinuxRen 发表于 2006年03月24日 21时42分
自己翻译过的一个文章

2038年一月19号，星期二，凌晨3点14分7秒钟的时候，如果Linux程序员会做恶梦的话，那么梦的内容一定是关于这个日期的，在这一秒钟滑过后，凡是安装着linux的计算机都会死机或者陷入死循环，这会给很多的数据库带来极大的麻烦。这个可不是那些反对linux的人胡编乱造得东东，而是linux自身的千年虫问题。

如果你想知道什么是2038问题的话，你需要知道一些技术上的东西。这个bug是由用来写linux的c语言引起的，c中用time_t来代表时间和日期，time_t是整数（int）型的，它用来记载从1970年1月1日到目前所经历的秒数。

这个数据是以32位存储的，第一位是符号位，其余的31位用来存数字，而这31位数字可以存储的最大数字为2147483647

从1970年开始计算，这31位的数字可以表示的秒数最多可以用到2038年，当时间到达这个数字的时候系统将会出现问题，到时候数字不会自动增加，而是会变为-2147483647，而这串数字代表的时间是1901年12月13号，这会导致很多的程序出现问题，甚至崩溃。

这个可比千年虫问题更具有破坏力，因为千年虫问题只会导致应用层的程序出现问题，比如信用卡支付系统，或者管理系统。而2038这个bug,将会影响系统最底层的时间控制的功能.

Raju Mathur,GNU 和 Linux的顾问兼Linux Delhi Users Group的斑竹，说：“我认为到时候首当其冲的将会是嵌入式领域，因为这个领域内的软件更新不是很频繁。流程控制系统，手机，游戏平台，电话的交换机等等这类的设备将会是最大的受害者。”

但是他后来补充道，以现在技术革新的速度，到时候估计不会有人还会使用32位的系统。

但是目前呢？很多运行在Linux上的程序可以计算到30年后的日期，对于抵押以及保险行业来说，可能在D-Day之前就会有问题出现。

Charles Assissi，Chip杂志的编辑说：“这个问题目前还不会让很多人惊慌，除了那些脾气不好的人”。

问题应该怎么分类解决呢？较新的Linux程序可以64位的或者更长的数据来表示时间，从而解决这个问题。对于现有的系统，可能c现在记录时间的方式将会被修改，然后所有的程序重新编译。作远远的要比说难得多。

Mathur 说：“如果没有上10亿行的代码在使用这个值的话，至少也有上百万行，找到它们，修改他们，升级嵌入式的系统，然后再重新部署，我认为是一项不可能的任务。”这会不会是另一个对于印度的开发团队来说很好的机会呢？

---
个人网站：www.linuxren.org
[ 回复此文 ]
脆弱的卡巴斯基
Anonymous 发表于 2006年03月24日 22时00分
很多windows程序都会有这个问题

基本上32位的os 中 time_t都是32bit
除了vs2005外

另外一个产品能使用十年已经够不错了

这东西基本上不用考虑
[ 回复此文 ]
脆弱的卡巴斯基
woood 发表于 2006年03月24日 23时45分
似乎当前的标准库和内核部分已经可以避免这个问题了,不过不能确定还有老式的程序中存在问题.同时,那种运行了几十年的程序或者几十年没有重新编译的程序也许也会出问题:)
[ 回复此文 ]
脆弱的卡巴斯基
Anonymous 发表于 2006年03月24日 22时39分
在虚拟机中测试了一下，没出现什么问题。系统FC4。
[ 回复此文 ]
脆弱的卡巴斯基
Anonymous 发表于 2006年03月25日 00时42分
php 的时间函数似乎也有这个问题. 上次调试一段php代码的时候发现的. 呵呵. 不过没怎么注意.
[ 回复此文 ]
脆弱的卡巴斯基
Anonymous 发表于 2006年03月25日 01时33分
病毒也会崩溃的。
[ 回复此文 ]