Windows设备名在UNC路径中仍允许路径遍历(CVE-2025-27210修复后)
摘要
我发现Windows设备名(CON、PRN、AUX等)在处理UNC网络路径时仍可用于路径遍历攻击,即使在CVE-2025-27210补丁之后。基本上,该修复仅覆盖了常规路径,但遗漏了使用path.join()时的UNC路径场景。
描述
在测试最近的CVE-2025-27210修复时,我注意到一些情况。该补丁对常规路径有效——如果我尝试path.normalize('CON:../../secret.txt'),它会正确返回.\CON:..\..\secret.txt。很好,这已修复。
但当我开始测试UNC路径(如网络路径\\server\share)时,发现漏洞仍然存在。问题是当你在UNC路径中使用path.join()和设备名时,设备名会被剥离,路径遍历发生。
示例代码:
|
|
这是因为path.join()内部的规范化函数处理UNC路径的方式与常规路径不同。
复现步骤
- 使用任何Node.js版本,包括最新的v24.4.1(带有CVE-2025-27210修复)。
- 创建一个简单的测试文件:
|
|
- 运行代码。
- 预期结果:
\\fileserver\public\uploads\.\CON:..\..\..\private\passwords.txt - 实际结果:
\\fileserver\public\private\passwords.txt(逃出了uploads目录!)
与CVE-2025-27210的不同之处
我知道你在想——“我们不是刚修复了这个吗?”嗯,算是。CVE-2025-27210通过添加.\前缀来修复常规路径的问题。但该修复仅适用于直接的normalize()调用或常规本地路径。
区别:
- CVE-2025-27210:修复了本地路径的
path.normalize('CON:../') - 此漏洞:UNC路径如
\\server\share+ 设备名在使用path.join()时仍易受攻击
这本质上是在网络场景中对CVE-2025-27210修复的绕过。
缓解措施
要修复此问题,应在path.join()函数中对UNC路径应用相同的设备名验证逻辑。具体来说,当连接以\\开头的路径时,代码需要检查设备名并添加.\前缀,就像对常规路径所做的那样。
修复可能需要放在规范化函数的UNC路径处理部分,围绕处理以\\开头的路径的地方。
影响
攻击者可以读取Windows网络共享上预期目录之外的文件:
- 文件共享应用程序(逃到其他用户的文件夹)
- 使用UNC路径的云存储系统
- 企业网络共享(访问敏感文档)
- 任何从网络位置提供文件的Node.js应用程序
此外,这可能导致企业网络中的横向移动——想象从\\webapp\public逃到\\webapp\C$\Windows\System32\config甚至其他服务器如\\adminserver\C$。
后续讨论
在报告提交后,开发者与Node.js团队进行了多次讨论。团队最初认为根据其威胁模型,用户应负责清理输入,因此此问题不被视为漏洞。但开发者指出,这与CVE-2025-27210的修复不一致,该修复针对相同的设备名问题但仅用于常规路径。
最终,Node.js团队审查后决定,根据其威胁模型,此类问题应被视为常规错误而非漏洞,并计划更新威胁模型以明确区分。报告被关闭为“信息性”,未分配CVE。
结论
此漏洞突显了安全修复中的一致性重要性,以及全面测试所有场景(包括边缘用例如UNC路径)的必要性。开发者应意识到,即使应用了安全补丁,仍可能存在未覆盖的攻击面。