【Day 04】CVE 哪有那麽萌 - 找漏洞经验分享

动机

这篇内容讲的是我在今年暑假参加 AIS3 暑期营队软件安全组所做的专题，队友分别为郑永泰、许智凯、林咏翔，主题是「找 CVE 好难」。

AIS3 是一个为期七天的活动，前五天会安排资安业界的讲者们授课，剩下两天是学员们的专题报告。学员要利用营队这段时间，根据自己所在的组别做出相关研究。一开始我们本来要做 IDA、Ghidra 的扩充功能，不过经过参考资料的搜寻後，发现要在短时间内做出一个没人做过的扩充功能有些难度。虽然後来发现其实不一定要做出一个完整的作品，而是看作品的想法好不好，例如有的组读论文并把论文的概念做成扩充功能。

总之当时我们就决定选几个 CVE 研究，但是看了一些觉得只报告 CVE 好像有点混，於是就想说那来找找看有没有漏洞。最後总共找到五个漏洞，回报专案负责人并有其中四个目前已经回覆或修复。虽然没领到 CVE，但仍旧是个有趣的经验。

附上一张组员合照，今年的 AIS3 因为疫情而在 Gather 举办。

方法

如前言所介绍，在开始进行专题前会先有相关的授课。听了来自 Devcore 的 Angelboy 和 Orange 的分享心得，得到了以下建议。

「找漏洞可以从⼩型的专案或是软件开始，顺便建立⾃我信⼼。」 - Angelboy
「可以多看看当前的 CVE，说不定没修好就可以找到另一个 CVE。」 - Orange

根据这些意见，我们决定找目前有的 CVE，并翻找可能有类似漏洞的专案。
从 MITRE 的 CVE 网站搜寻关键字，因为我们是软件安全组，然後我自己是希望找 Windows 相关的漏洞，所以关键字是下「windows」。

结果有好几千个其实也算是意料之内，於是我们从最新的漏洞开始用工人智慧一则一则看，挑选出小型、熟悉的语言、最好有开源的专案。基本上这些条件加上去後，能选择的就少了许多。当然还是不可能把所有看完，大概只看了 2017 年以後的 CVE。

CVE-2019-17664

漏洞资讯

CVE-2019-17664 是个发生於 Windows 作业系统的 Ghidra 漏洞。它被发现在使用 Ghidra Python 时会执行 cmd.exe，这导致假如有个档名为 cmd.exe 的恶意程序在同个目录中，就会在使用 Ghidra Python 时执行这个恶意程序。

漏洞成因

看了 Ghidra Issue #107 的讨论後发现，其实出问题的不是 Ghidra，而是 Jython。Jython 的 PySystemState.java 执行了 cmd.exe，却没有检查可能是执行到目录下的 cmd.exe 而导致了这个漏洞。

官方修复

目前这个 Jython Issue 2882 也有人回报了，预计会在 2.7.3 版本修复。

以洞找洞

我们找到几个有使用 Jython，并且有办法利用这个 CVE 完成攻击的专案。这里有个重点是「能够利用」，因为如果一个漏洞没有办法利用，它可能就不会被视为一个漏洞。

最终我们找到两个专案，MeteoInfo 和 fiji 能够利用这个漏洞。

漏洞回报

漏洞已回报在 MeteoInfo Issue #16 和 fiji Issue #291。目前只有 MeteoInfo 专案负责人回覆了「Thanks for this issue report!」。

CVE-2020-35112

漏洞资讯

CVE-2020-35112 是个发生於 Windows 作业系统的 FireFox 漏洞。当一个使用者下载了一个档案，假设档名为 test，且没有副档名，则当使用者点选下面的下载面板想要开启它时，如果同个目录下有档名为 test.exe 或 test.bat 的档案，它就会被执行。

漏洞成因

程序中使用了 ShellExecuteExW 执行指令，在打开没有副档名的 test 档案时会执行 test.exe 或 test.bat，这也算是 Windows 的历史共业。

官方修复

後来的修复方法是在 Windows 中假设现在下载的是一个没有副档名的档案，则不会尝试开启它，而是开启档案所在的目录。

以洞找洞

我们找到 FarManager 这个专案也有相同问题，它是一个 Command Line 程序，用来浏览或管理目录与档案。我们发现它也有相同的问题，假设同个目录有 test 档案与 test.exe 或 test.bat 档案，当 FarManager 试图开启 test 档案时，会执行到 test.exe 或 test.bat。

漏洞回报

漏洞回报在 FarManager Issue #428，目前已经修复了。

CVE-2021-21237

漏洞资讯

CVE-2021-21237 是个发生於 Windows 作业系统的 git-lfs 漏洞。如果在执行 git-lfs 指令的同个目录下有档名为 git.exe 或 git.bat 的恶意程序，它们会被执行。

漏洞成因

专案使用了 golang 1.8 的 exec.Command 来执行 git。它预设会先找目前所在目录的执行档，而不是环境变数中的，导致如果有个 repo 中放有档名为 git.bat 或 git.exe 的恶意程序，git-lfs 会执行到它们而不是使用者环境中的 git。

官方修复

在专案中的 exec.Command 外面包一层自己定义的 subprocess.ExecCommand，其中会对指令做检查。

golang 那边後来也把 exec.Command 的预设行为修掉了，所以就算是旧版本的 git-lfs 也不会触发漏洞。

以洞找洞

我们在重现这个漏洞时发现一个状况，就是如果没有下载 git，也就是环境变数中没有 git 指令，在这个情况下假设同个目录中有 git.bat 或 git.exe，它们就会被执行。

後来经过跟 git-lfs 的负责人沟通後，发现原因是 Windows 的环境变数中包含了当前目录，这会发生在环境变数 Path 中是以分号 ; 结尾的情况。

在 cmd 中打 set | find "Path" 指令会出现许多路径。
在这个例子中环境变数是没有包含当前目录的:

Path=C:\Windows;C:\Windows\System32

下面这个例子就会包含当前目录:

Path=C:\Windows;C:\Windows\System32;

漏洞回报

因为这个专案有提供 Security Policy 说明如何回报漏洞，所以一开始是用 Email 与负责人联系。後来我发了 PR #4562，负责人也给予了正式的回应。但是这个专案的 Workflow 太难通过了，还要写复杂的测试程序，所以最後还是交给他们在 PR #4603 修复。

一开始 git-lfs 的负责人不认为这是他们的问题，因为他们觉得环境变数包含当前目录是一件不该发生的事。後来我们跟负责人解释说有些 Windows 的版本预设情况下的环境变数就会包含当前目录，例如 Windows Server 2019，但是他们还是觉得这算是 Windows 的责任。然而基於安全考量，他们还是愿意在程序中检查这个问题。

心得

这次活动找到的漏洞难度很低，性质也很相近，都是 Windows 处理档案的问题造成的，只是分别使用 C、Java、GO 语言。虽然难度不高，但是能在短短的营队期间就达成这样的成果，我认为还算是满意。而且经过这次经验，我觉得我和找漏洞之间的距离又更近了一步，期许自己以後能够发一个超猛 CVE。