系统时间随机跳到 55 天后,程序出 Bug,开发者:这是 Windows 系统功能搞得鬼!

VSole2023-08-30 08:56:44

一直以来,操作系统的「时间、日期、时区」,是让很多程序员在开发程序时比较敏感与特别关注的问题。

  • 还记得即将步入 2000 年的“千年虫”(Year 2000 Problem,简称“Y2K”)事件,由于早期的计算机配置比较低,那时为了节省空间就把年份只用后两位数表示,如 1999 就表示为 99,导致新千年时电脑把 2000 年认为是 1900 年,出现 Bug,进而引发各种各样的系统功能紊乱甚至崩溃。
  • 2012 年,有用户发现低内核版 Linux 开启 NTP 服务器会遇到闰秒 Bug,导致服务器重启。
  • 2016 年,很多网友“作了一把”,将 iPhone 的日期设置到 1970 年 1 月 1 日,无意中触发系统 Bug,一时间导致 iPhone 重启失败,手机直接变板砖。

就在近日,一个新的关于时间 Bug 出现在 Windows 系统中。据 Ars Technica 报道,有一位挪威数据中心的工程师 Simen 遇到了一个令人费解的时间 Bug, 它会导致 Windows Server 突然将系统时钟重置到未来 55 天。

1、时间 Bug 带来的混乱

事实上,这并不是 Simen 第一次遇到这个问题。

在去年 8 月,Simen 曾遇到过类似的错误,当时一台运行 Windows Server 2019 的机器将时钟重置到了 2023 年 1 月,但过了没多久又自动跳回来了。

后来,直到事件日志被清除后才发现这一问题,但那时无法分析具体是什么原因导致的。

现在,他又在一台运行 Windows Server 2016 的机器上遇到了这个问题。

对于普通用户而言,时间的错乱带来的短暂影响也许可以忽略不计。但是对于工程师而言,却是一个让人崩溃的存在。

Simen 的主要工作是在 Windows Server 维护一个路由表(存储在联网计算机中的电子表格(文件)或类数据库),这个路由表实时跟踪手机号码从一个运营商转到另一个运营商的过程。

当服务器出现时间 Bug 时,系统时钟跳到八周后,这就带来一个不可估量的后果,譬如,此前尚未迁移的号码被列入已经迁移、已经转移的号码被列为待处理状态,整个都乱掉了。

2、无独有偶

本来以为这只是一个特例,但是搜索一下,网络上遇到这个问题的工程师不在少数。

去年,有一位名叫 Ken 的工程师也发现了类似的“时间跳跃”现象,当时在 2-3 台服务器上,时钟时不时会跳跃到几周后,甚至有一次直接跳到了 2159 年。

据 Ars Technica 披露,Ken 在一封邮件中写道:“受此影响的服务器呈指数增长,越来越多。在 5000 台服务器(虚拟机)中,我们总共有 20 台左右的服务器(虚拟机)遇到过这种情况。这种情况通常发生在数据库服务器上。当数据库服务器在时间上发生跳跃时,就会造成严重破坏,只要服务器在时间上有如此大的偏移,备份也就无法运行。对于我们的客户来说,这一点至关重要。”

除了 Simen 和 Ken 之外,追溯到 2017 年,一位 Reddit 用户 zanatwo 发帖称他在一所大学工作,某一天,其发现校园内的几台 Windows 10 计算机开始出现错误的时间。这些计算机上显示的时间 Bug 完全是随机的,在某些情况下,他的设备时间直接跳到了 31 个小时之前。

通过深入分析,当时 Reddit 用户发现,时间变化与 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\SecureTimeLimits 中的 Windows 注册表键相关。进一步的调查显示,当一些人试图访问大学网站时,这些错误报告称网站使用的有效 SSL 证书无效。

3、Windows 官方发布的功能惹了祸?

经过排查之后,以上几位工程师将罪魁祸首统一定位到了 Windows 上一个鲜为人知的功能—— Secure Time Seeding(简称 STS)中。

这是微软在 2016 年引入 Windows 的功能,主要作用就是在 Windows 设备无法通过安全连接与时间服务器通信的情况下,改进对正确时间的记录。简单来看,这也是设备在断电情况下也能保证准确的时间。默认情况下,这一功能在 Windows 系统及服务器下是打开的。

从工作原理来看,为确定当前时间,STS 会调用 SSL(Secure Sockets Layer)握手过程中包含的一组元数据。具体来说,这些数据包括:

  • ServerUnixTime,日期和时间表示法,显示自 1970 年 1 月 1 日 00:00:00 UTC 时起已过去的秒数。
  • 从远程服务器 SSL 证书中获取的加密签名数据,显示该证书是否已根据所谓的 "在线证书状态协议 "机制被撤销。

在发布这一功能时,微软工程师在官方文档中写道,他们使用 ServerUnixTime 数据是 "假定它在一定程度上是准确的",但在同一句话中又承认它 "也可能是不正确的"。

为了防止 STS 根据单个不同步远程服务器提供的数据重置系统时钟,STS 会随机穿插 SSL 连接到多个服务器,以得出当前时间的可靠范围。

然后,该机制会将 ServerUnixTime 与 OCSP(Online Certificate Status Protocol,在线证书状态协议 )有效期合并,以产生尽可能小的时间范围,并为其分配置信度分数。

当分数达到足够高的阈值时,Windows 就会将数据归类为 STSHC(Secure Time Seed of High Confidence,高置信度安全时间种子)。然后,STSHC 用于监控系统时钟是否存在 "严重错误",并对其进行纠正。

尽管 STS 内建了检查和平衡机制,以确保其提供准确的时间估计,但长期以来工程师遇到的“时间跳跃”事件表明,该功能有时会做出误差数天、数周、数月甚至数年的胡乱猜测。

Ars Technica 报道的文章中,其分享了来自工程师 Ken 遇到时间跳跃时的具体截图。

第一张图片中的选定行上方的 "预计安全时间 "条目显示,Windows 预计当前日期为 2023 年 10 月 20 日,比系统时钟显示的时间晚四个多月。然后,STS 会更改系统时钟,使其与"目标系统时间 "中显示的错误的预计安全时间相匹配。

第二张图片显示了类似的情况,其中 STS 将日期从 2023 年 6 月 10 日改为 2023 年 7 月 5 日。

在遇到这一问题后,Ken 和 Simen 都向微软进行了反馈,遗憾的是,他们并没有得到实质性的回应与解决方案。

4、微软工程师个人曾发出警告:主动关闭 STS 功能

那要问有没有解决方法,其实去年一位微软 Windows 高级工程师 Ryan Ries 发过推文提供过用户,其写到“大家好,如果你们管理 Active Directory 域控制器,我想给你们一些非官方的建议,这完全是我的个人意见:在您的 DC 上禁用 w32time 的 STS。”

当有网友进一步询问原因时,Ryan Ries 表示,「因为在它咬你的屁股之前,这只是一个时间问题」。

这也不禁让人好奇,连微软自家工程师都觉得这个功能有问题,为什么官方还有做保留。

就在众人存疑时,微软在给 Ars Technica 的一份声明中写道:

STS 功能是一种基于启发式的计时方法,在某些软件/固件/硬件计时失效的情况下也有助于校正系统时间。该功能已在所有默认 Windows 配置中默认启用,并已证明在默认配置中发挥了预期功能。

每次部署的时间分配都是独一无二的,客户通常会根据自己的特殊需求来配置机器。鉴于 "STS"的启发式性质以及客户可能使用的各种部署,我们提供了禁用该功能的选项,以满足客户的需求。我们的理解是,在客户遇到 STS 问题的部署中,很可能存在独特、专有、复杂的因素,而这些客户并不能从目前实施的这一功能中受益。在这些个别情况下,我们只能建议在部署中禁用该功能。

具体来看,要禁用 STS,可以在受影响的机器上设置一个注册表项。这是 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config 目录中的 UtilizeSslTimeData 密钥,其类型为 REG_DWORD。如果设置为 0,则停用 STS。如果设置为 1,则可以重新激活该功能。

5、STS 的异常,有没有解决方案?

截至目前,似乎除了关闭此功能之外,并没有太过合适的解决方案,因此,很多人对于微软的回应并不买账。在 HN 上,网友也展开了激烈的讨论,甚至有人吐槽:是时候应该买块手表来核对服务器上的时间了!

另外,有网友 @theqmann 分析认为,「这听起来像是一种统计方法,如果在给定时间内收到 N 个时间戳相似的数据包/连接,就会改变时钟。我可以看到这样一个问题:一台 Windows Server 每分钟全天候提供数千或数百万个 OpenSSL 数据包,而它恰好随机接收到 N 个数据包,这些数据包彼此非常接近,足以满足统计阈值的要求。通过随机跳转,连续跳转十多次时间都是有可能的」。

@jmuguy 则表示:

在我做 IT 人员的这些年里,Windows Time 是我处理过的最烦人的事情之一。注册和取消注册 w32time,尝试不同的 NTP 服务器。试图弄明白为什么域系统无法从 DC 获取时间。这总让人感觉很......愚蠢。在设备上设置正确的时间肯定没那么复杂。事实证明,并不复杂,除非你使用的是 Windows 系统。有点讽刺的是,如今我唯一需要处理的 Windows 系统就是我的游戏电脑。它拒绝与 time.windows.com 同步。

除了 Windows 系统之外,还有人称在 Linux 中也遇到了同样的问题。

@nicolaslem 表示: 

我的 Linux 笔记本电脑有时也会遇到类似的问题,把电脑从睡眠中唤醒时,时间会跳到 2077 年。我猜这是硬件故障,因为它并不经常发生,但一旦发生就会造成很大影响。我无法想象在生产服务器上发生类似情况会有多大影响。

你是否遇到过类似的问题?

sts时间服务器
本作品采用《CC 协议》,转载必须注明作者和本文链接
一直以来,操作系统的「时间、日期、时区」,是让很多程序员在开发程序时比较敏感与特别关注的问题。
时间线2022 年 5 月 25 日:向 AWS 安全部门报告了该漏洞。EKS 团队开始将更新版本部署到所有地区。AWS IAM Authenticator 是位于 Kubernetes 集群控制平面内的组件,可使用用户和角色等 AWS IAM 身份进行身份验证。该项目目前由 Amazon EKS Engineers 维护。
VMware Inc. 是一家软件公司。它开发了许多产品,尤其是各种云解决方案 。他的云解决方案包括云产品,数据中心产品和桌面产品等。
在内网渗透中常常会碰到VmwareVcenter,对实战打法以及碰到的坑点做了一些总结,部分内容参考了师傅们提供的宝贵经验,衷心感谢各位师傅!
它的云解决方案包括云产品,数据中心产品和桌面产品等。它包括了 vCenter Server, ESXi 和 vSphere client,是整套虚拟化部署方案的总和。是 vSphere 中最重要的一个组件。而 vSphere client 有更加详细的性能监控,批量更新接管所有 ESXi 系统版本。在 6.0 版本之后,官方已经取消了 C/S 架构的客户端,转而采用了 web 管理平台,又被称之为 vSphere web client。官方推荐将打包好的 Client 与 Server 应用部署在 VMware 自家的 Photon 系统下,其安装包命名为:VMware vCenter Server Appliance,简称为:VCSA。
Lightspin 的研究团队在 RDS 服务上,利用 PostgreSQL 数据库中的 log_fdw 扩展功能所存在的本地文件读取漏洞,获得了一个 RDS 服务所在 EC2 实例上的访问凭证,这个访问凭证与 AWS 内部账号相关联。 该漏洞报告给了 AWS 安全团队,他们很快就打一个初始补丁,不过仅限于比较新的 RDS 服务版本和 Aurora PostgreSQL 引擎,不包括旧版本。
作者:知道创宇404实验室翻译组原文链接:... 一、摘要 网络安全报告书由网络安全基础设施安全局(CISA)、联邦调查局(FBI)和美国网络司令部国家宣教部队(CNMF)联合撰写,主要描述了针对朝鲜高级黑客组织Kimsuky...
开源工具是网络安全团队武器库中必不可少的利器,在云计算普及的今天,虽然云安全厂商们大多提供了本机安全工具套件,但是随着云应用和云负载的不断增加,IT团队经常会发现云计算平台的安全开发、合规性和管理工作负载的能力与实际需求存在差距,而很多开源云安全工具则能弥补这个空白。以下,我们推荐七个2021年值得关注的云安全开源工具。
Lookout Threat Lab的研究人员发现哈萨克斯坦政府在其境内使用企业级Android监控软件。我们于2022年4月首次检测到来自该活动的样本。根据意大利下议院在2021年发布的一份文件,意大利当局可能在反腐败行动中滥用了这个软件。该文件提到了iOS版本的Hermit,并将RCS Lab和Tykelab与恶意软件联系起来,这证实了我们的分析。
在安全防御端的研究中,或者作为安全防御端研究人员,我们常常都会站在攻击者的角度或攻击向量切入点来思考安全防御问题,这些攻击者一般来说都是来自信任区域之外的威胁行为者。但是,如果攻击者已经成功进入了我们的信任区域,并且想要获取我们的数据,此时该怎么办呢?
VSole
网络安全专家