diff检查逻辑存在缺陷

由于Homebrew项目使用GitHub Actions运行CI脚本，小哥查看了.git-hub/workflows/下每个仓库的目录。

其中两个目录：一个负责检查用户提交的拉取请求的内容，进行批准，另一个目录负责自动合并这些被批准的代码。

拉取请求的内容被fetch后会被改为diff文件，并使用git_diff对其进行解析。

小哥一开始检查了可以通过批准请求的几个条件，没有发现问题。

但是直觉作怪，他还是掉过头去二次研究了git_diff仓库。

当看到其中报告了一个“更改行数引发解析错误”的问题时，小哥“灵机一动”：

我是不是能以某种方式对拉取请求进行伪装来满足批准条件，骗过git_diff？

于是他分析了git_diff解析diff文件的步骤，乍一看没毛病，但是细看其中一步发现了“猫腻”：可以多次更改源/目标文件路径信息。

于是通过下面这两行代码：

   "b/#{私藏代码写这儿}"
   b/Casks/cask.rb

第一行将私藏代码以上面的格式嵌入拉取请求，就可以被视为文件路径信息，而非代码变动。

第二行为更改文件路径的必需条件。

这样就可以绕过必需条件，将含有恶意代码的拉取请求视为零行更改的

“无害”请求，最终骗过diff，获得批准，完成自动合并！开始搞事情！

添加“打印日志”操作来验证此漏洞

“今天的收获可不菲”，小哥立即行动，提交了一个PR，通过Homebrew搞起了破坏，在HackerOne上对此漏洞进行PoC演示。

以下是具体代码：

（选取在GitHub上无意发布了一个API令牌的拉取请求iterm2.rb 进行更改）

   "b/#{puts \'Going to report it - RyotaK (https://hackeorne.com/ryotak)\';b = 1;Casks = 1;iterm2 = {};iterm2.define_singleton_method(:rb) do 1 end}"
   b/Casks/iterm2.rb

在第一行定义b，Casks，iterm2，iterm2.rb四个变量，才不会在第二行引发未定义错误，这样就可以作为有效的Ruby脚本执行。

通过添加这两行更改，GitHub返回以下差异：

diff --git a/Casks/iterm2.rb b/Casks/iterm2.rb
index 3c376126bb1cf9..ba6f4299c1824e 100644
--- a/Casks/iterm2.rb
    b/Casks/iterm2.rb
@@ -8,6  8,8 @@
     sha256 "e7403dcc5b08956a1483b5defea3b75fb81c3de4345da6000e3ad4a6188b47df"
   end
    "b/#{puts \'Going to report it - RyotaK (https://hackeorne.com/ryotak)\';b = 1;Casks = 1;iterm2 = {};iterm2.define_singleton_method(:rb) do 1 end}"
    b/Casks/iterm2.rb
   url "https://iterm2.com/downloads/stable/iTerm2-#{version.dots_to_underscores}.zip"
   name "iTerm2"
   desc "Terminal emulator as alternative to Apple\'s Terminal app

如前面所述，git_diff将匹配的行 “?b/(.*) 视为文件路径信息，而非添加的行，因此，此差异将被视为进行0行更改的请求。

由于既不能修改未经授权使用的cask，也没有在homebrew-cask仓库中找到一个测试cask，小哥给Homebrew发邮件求助，按照工作人员的意思添加“打印日志”这一无害修改来验证了这个漏洞。

当其他用户执行brew search/brew cleanup等命令时即使没有安装目标cask，也将执行恶意代码。

官方在3小时之内完成了主要修复，并发布了通报。

“这不是单方面的责任”

针对这次大漏洞，网友们议论纷纷，有人表示：

如果不是使用ruby解析git_diff，而是使用libgit，这个漏洞就不会发生。

如果Apple提供了一个功能更强大的软件包管理器，这不会发生。

如果数以百万计的Homebrew用户给了他们建造如此庞大的项目所需资金的一小部分，这也不会发生。

此漏洞没有单一负责方。

另外，细心的朋友可能还记得，我们此前曾报道了一篇关于黑客用GitHub服务器挖矿的新闻，里面的黑客也是只需提交Pull Request，即使项目管理者没有批准，恶意挖矿代码依然能够执行。

和这次这个漏洞一样，都是抓住了GitHub Actions的自动执行工作流功能来“钻空”。

针对滥用Actions的问题，GitHub近日也更新了帮助保护维护者的新功能，比如在任何Actions工作流运行之前，来自首次贡献者的Pull Request将需要**具有写访问权限的仓库协作者的手动批准**。

参考链接：
[1]https://blog.ryotak.me/post/homebrew-security-incident-en/
[2]https://news.ycombinator.com/item?id=26922448
[3]https://brew.sh/2021/04/21/security-incident-disclosure/
[4]https://wangzhan.360.cn/774.html
[5]https://github.blog/2021-04-22-github-actions-update-helping-maintainers-combat-bad-actors/

— 完 —

内容出处：，

声明：本网站所收集的部分公开资料来源于互联网，转载的目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。如果您发现网站上有侵犯您的知识产权的作品，请与我们取得联系，我们会及时修改或删除。文章链接：http://www.yixao.com/tech/23629.html