Mac包管理工具Homebrew出现了一个大漏洞:
在Homebrew/homebrew-cask仓库中,通过混淆Homebrew项目中自动拉取请求审阅脚本中使用的库,可以合并恶意的拉取请求。
如果被滥用,攻击者可以在使用brew的计算机上执行任意Ruby代码!
该漏洞的威胁登记在国内被360CERT评为10分严重。
漏洞的发现者是一位来自日本的后端程序员。
当天下午,他“闲来无事”逛起了HackerOne(漏洞赏金平台)。顺便看看经常使用的Homebrew有没有什么漏洞。
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'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/Casks/iterm2.rbb/Casks/iterm2.rbindex3c376126bb1cf9..ba6f4299c1824e100644---a/Casks/iterm2.rb b/Casks/iterm2.rb@@-8,6 8,8@@sha256"e7403dcc5b08956a1483b5defea3b75fb81c3de4345da6000e3ad4a6188b47df"end "b/#{puts'Goingtoreportit-RyotaK(https://hackeorne.com/ryotak)';b=1;Casks=1;iterm2={};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/(.*) 视为文件路径信息,而非添加的行,因此,此差异将被视为进行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/
— 完 —
量子位 QbitAI · 头条号签约
关注我们,第一时间获知前沿科技动态