在*nix平台上配资炒股流程,如果对不受信任的仓库执行clone --recursive,可能会导致远程代码执行。Git最新漏洞CVE-2025-48384影响老版本(Git v2.50.0及以下版本)的Git以一些以git为内核其他客户端,比如GitHub等。
缘起
老式机械打字机,当打字到一行结束时候,可通过物理动作(Carriage return)以回到行首。这个操作在打字机内部,通过一个拉杆来实现的。后续改进后,专门为其增加一个按键。这就是回车符(),在ASCII中,这个键被表示为“”,字符编号为13,图标为“↵”。现代键盘上的“Enter”或“Return”键经常会用到这个符号动作。以及移动到下一行的动作换行(line feed),表示为“”。
这个早期通信系统延续下来的问题,仍然影响着今天的软件系统。CRLF的处理在*nix和Windows中有各自不同的处置方法,在*nix系统将其简化,只使用LF代替,C语言中用“\n”来表示,用来处置行的分隔,在Windows中(以及各种互联网协议中则使用CR+LF的方式,对应的键位“\r\n”)。
漏洞
今天要说的这个Git漏洞来源和这个处置方式密切相关。
git的.ini配置格式,如下所示:
[section]key = value
如果这只是在用户端的配置文件中使用,那么就不会有担心可接受的格式。然而,.gitmodule配置格式也是该格式。.gitmodule用于配置git子模块的存储库跟踪。
上述格式支持Windows式的行分隔符(CRLF)。在处理中,只是简单将其清除,相关源代码如下:
其中cs->do_fgetccall几乎等同于标准C函数fgetc,该函数的功能很明显:如果读取的字符是回车符(\r),然后继续读下一个字符,如果是换行符(\n),则直接返回换行符(清理掉回车符)。但是,如果下一个字符不是换行符,返回回车符(\r)并将下一个字符返回检查状态(ungetc),继续正常读取。
注意:类似的处理在很多系统源码都中都有。
需要注意的关键是,该函数执行按行进行的。因此,如果对于某些一行恰好以CR结尾,它将被删除,而不管文件的整体格式如何。
除了读取配置的代码之外,git还可以写入配置文件,例如当用户使用git config命令设置配置,它会使用下面的代码来写入key = value写入配置文件。
漏洞的发生在于get_next_char函数与这个代码关联处理中。在配置读取代码的其他地方,git支持以双引号括起来的引用字符串。但是,当它将值写到配置文件时,只有当某些文件包含空格时才会对其引用,或使用;引用后面的你哦给你或者#任何地方。这样当它稍后读取值时write_pair写入配置文件,它可以被欺骗,删除最后面的\r字符。
所以,如果有一个文件 key = "foo^M"(在文本编辑器中CR会显示为^M),当被读取然后写回来时就会变成 key = foo^M。
对于一个不可信的.gitmodules配置,可以以类似的方式足已混淆配置解析器。
在基于*nix的系统中,其文件名中支持使用控制字符,对一个如下的路径配置 .gitmodules将尝试将模块签出到以控制字符命名的目录中。
[submodule "foo"]path = "foo^M"
然而,当通过git的配置代码将其写到.git/modules/foo/config,实际形式是:
.gitmodules已针对读取的不受信任路径进行了验证。这意味着路径在验证之后发生了本质上的变化,因为当读取时,配置读取代码会剥离最终的\r。
利用bug来创建包含子模块的仓库,并欺骗Git将文件写入.git/目录而不是子模块的工作树。这样就可以编写一个hook,在克隆操作仍在运行时执行,使用户没有机会检查正在执行的代码。
所有这些的结果是,当执行子模块克隆时,由于没有没有结束与^M它可能会读取一个位置来自path = ...,但写出一条不同的路径。
这个简单的原语足以让git感到困惑,以至于当它检出一个子模块的内容将被写入不同的路径。这非常类似于CVE-2024-32002(子模块中不区分大小写)可能会造成混淆 git。
这个bug需要一个不区分大小写的文件系统,也就是这个需要一个允许在文件名中使用控制字符的文件系统,因此Windows不会直接受到此特定漏洞的影响(而*nix和macOS则会易受CVE-2024-32002和 VE-2025-48384攻击)。
在命令行上克隆时,git clone仅靠它本身不足以克隆子模块,因此手动缓解的方法是使用git clone (无—recursive)检查 .gitmodules检查它是否安全然后初始化子模块。
然而GitHub Desktop默认情况下会自动使用递归选项进行克隆,因此如果使用GitHub Desktop进行克隆,则可能会自动克隆一个包含hook的子仓库,从而实现远程执行。
这个漏洞的解决也非常简单,从补丁源码中可以看出,只需确保write_pair,当需要写的字符串中有一个回车符,则用引号引起来。
混淆写入原语可用于将恶意文件从几乎可以在文件系统的任何位置使用子模块,并实现任意文件写入(因为它绕过了验证,所以它可以跟踪外部的符号链接存储库)。利用这一点的最直接方法是用它来编写.git目录,在里面并创建hook脚本,这样当Git运行hook时,攻击者可以控制代码执行。除此之外还支持其他的可能攻击方式,例如覆盖.git/config。相关PoC,可以直接稍微修改一下CVE-2024-32002漏洞的代码即可。
总结
这不是第一个也不是最后LRLF问题导致的漏洞(类似问题还有UTF-8的bom问题)。仅仅Git,就发生过:CVE-2025-23040凭证辅助协议的问题;
CVE-2024-53263换行符注入导致凭证泄;
CVE-2023-29007任意配置注入漏洞。
同时这类问题也并不是C语言系统独有的问题,在许多语言和网络协议也都出现了很多类似的漏洞。
最后提醒下:请及时升级你系统的Git版本配资炒股流程,目前最新版本Git v2.50.1已经解决了这个问题和其他几个漏洞。
思考资本提示:文章来自网络,不代表本站观点。