Homebrew存在较大漏洞，恶意代码可远程控制电脑Mac包管理工具Homebrew存在较大漏洞：在Homebrew/homebrew-cask仓库中，恶意pullrequest可以通过混淆自动使用的库进行合并Homebrew项目中的拉取请求审查脚本。如果被滥用，攻击者可以使用brew在机器上执行任意Ruby代码！该漏洞的威胁登记被中国的360CERT评为10级严重。该漏洞的发现者是一名来自日本的后端程序员。下午，他“无所事事”地访问了HackerOne（一个漏洞赏金平台）。顺便看看经常用的Homebrew有没有漏洞。diff检查逻辑存在缺陷由于Homebrew项目使用GitHubActions运行CI脚本，我检查了.git-hub/workflows/下各个仓库的目录。其中两个目录：一个负责检查用户提交的pullrequest的内容是否审核通过，另一个负责自动合并审核通过的代码。提取请求的内容并将其更改为diff文件，该文件使用git_diff进行解析。一开始，小哥检查了几个可以通过审批的条件，都没有发现问题。但是他的直觉是错误的，于是转身对git_diff仓库进行了第二次研究。当看到报“改变行数导致解析错误”的时候，小弟灵机一动：能不能通过某种方式伪装pullrequest以满足审批条件，骗过git_diff？于是他分析了git_diff解析diff文件的步骤。乍一看没什么问题，但仔细看一步，他发现“猫腻”：源/目标文件路径信息可以多次更改。于是通过下面两行代码：++"b/#{Privatecodewritehere}"++b/Casks/cask.rb第一行把privatecode按照上面的格式嵌入到pullrequest中，就可以了被用作文件路径信息，而不是代码更改。第二行是更改文件路径所必需的。这绕过了将带有恶意代码的拉取请求视为零行更改的“无害”请求的要求，最终欺骗差异，获得批准并进行自动合并！开始做事！添加“打印日志”操作验证此漏洞“今天的收获不便宜”，小哥立即行动起来，提交了一个PR，通过Homebrew造成破坏，并在HackerOne上对该漏洞进行了PoC演示。下面是具体代码：（选择GitHub上不小心发布了一个APItoken的pullrequestiterm2.rb进行修改）++"b/#{puts'Goingtoreportit-RyotaK(https://hackeorne.com/ryotak)';b=1;Casks=1;iterm2={};iterm2.define_singleton_method(:rb)do1end}"++b/Casks/iterm2.rb第一行定义了四个b,Casks,iterm2,iterm2.rb变量这样它就不会在第二行抛出未定义的错误，因此它可以作为有效的Ruby脚本执行。通过添加这两行更改，GitHub返回以下差异：diff--gita/Cas??ks/iterm2.rbb/Casks/iterm2.rbindex3c376126bb1cf9..ba6f4299c1824e100644---a/Cas??ks/iterm2.rb+++b/Casks/iterm2.rb@@-8,6+8,8@@sha256"e7403dcc5b08956a1483b5defea3b75fb81c3de4345da6000e3ad4a6188b47df"end+++"b/#{puts'Goingtoreportit-RyotaK(https://hackeorne.com/ryotak)';b=1={Casiterm2=1};iterm2.define_singleton_method(:rb)do1end}"+++b/Casks/iterm2.rburl"https://iterm2.com/downloads/stable/iTerm2-#{version.dots_to_underscores}.zip"name"iTerm2"desc"TerminalemulatorasalternativetoApple'sTerminalapp如前所述，git_diff将匹配行+++"?b/(.*)视为文件路径信息，而不是添加的行，因此此diff将被视为0行更改请求。由于未授权使用的cask既不能修改，也不能在homebrew-cask仓库中找到一个testcask，小弟发邮件给Homebrew求助，加了一个“打印日志”的无害修改来验证根据工作人员的意愿。这个漏洞。当其他用户执行brewsearch/brewcleanup等命令时，即使没有安装目标cask也会执行恶意代码。官方在3小时内完成大修，并下发通知。“这不是单方面的责任。”对于这个大漏洞，网友议论纷纷。有人说：如果用libgit而不是ruby来解析git_diff，就不会出现这个漏洞。如果Apple提供更强大的包管理器，就不会发生这种情况。如果数以百万计的Homebrew用户只给了他们构建如此庞大项目所需资金的一小部分，这也不会发生。没有任何一方对此漏洞负责。另外，细心的朋友可能还记得，之前我们曾报道过一则黑客利用GitHub服务器挖矿的新闻。里面的黑客只需要提交一个PullRequest。即使项目经理不认可，恶意挖矿代码依然可以执行。.像这次的漏洞，就是抓住了GitHubActions的自动执行工作流功能来“钻坑”。针对Actions的滥用问题，GitHub近期也更新了新功能来帮助保护维护者。例如，在任何Actions工作流运行之前，来自首次贡献者的拉取请求将需要具有写入权限的仓库协作者的手动批准**。
