G.O.S.S.I.P 阅读推荐 2024-02-21 危险的VS Code插件

先看一则今天的新闻：

Visual Studio Code应该是毫无疑问的宇宙最火IDE（EMacs用户不服来辩），但是在今天推荐的这篇名为UntrustIDE: Exploiting Weaknesses in VS Code Extensions的NDSS 2024论文中，作者系统地总结了当前VS Code所使用的插件的安全风险，告诉我们危险就在身边。

插件这个概念早在上个世纪就在软件生态中出现了，上了年纪的读者肯定对Winamp播放器的各种插件有印象吧？到了2020年代，插件在浏览器生态里面发挥了重要的作用，很多开发者也开始往VS Code上移植插件。和浏览器的插件相比，VS Code插件的一个主要的安全风险在于没有sandbox isolation，插件可以在整个VS Code的进程空间里面“为所欲为”（下图），因此如果插件有安全风险，直接就威胁了开发者的系统。

也许你会以为这篇论文关注的是恶意的VS Code插件，但是作者说：不对。本文揭示了另一类安全风险——VS Code插件本身并没有主动的恶意行为，可是因为一些设计上的不严谨，导致了攻击者可以执行data only attack——通过一些恶意的数据（例如配置文件），让插件执行非预期行为。2021年Snyk就在一个流行的VS Code插件——+LaTeX Workshop extension里面发现了相关安全漏洞（下图）。这个插件的问题在于它会在本地启动一个web server，开放一个特定的端口。而如果用户在使用VS Code的时候也打开了浏览器，浏览器中的网页就可以尝试去访问这个本地的网络通信通道（当然，网页并不知道用户是否装了这个插件，只能尝试），然后弹一个计算器（手动狗头）。

此外，由于VS Code插件高度依赖于npm（因为VS Code本身是基于Electron开发，VS Code插件也类似于Node.js应用），而npm这个生态里面鱼龙混杂的现象太严重了，所以产生了又一类威胁。

本文作者调查了43436个VS Code插件（其中25402个包含了JS代码），分析的方法是利用CodeQL写了12条规则，然后去扫描这些插件是否存在潜在的危险数据流——从四类攻击点流向三类攻击目标。作者用CodeQL扫描，检测出存在四类资源使用（如下图）的VS Code插件的数目：

下面我们就具体介绍一下安全检测技术。下表定义了安全威胁的来源：包括VS Code插件可能访问的文件、网络响应和因为启动了一个web server而收到的request，还有就是VS Code插件会访问的本地配置文件：

这最后一个来源比较有意思，如果有一个攻击者推测出你会用VS Code插件，那么ta可能会在ta的开源项目里面放一个特定的配置文件，然后等你来clone并且用VS Code打开。一旦你的VS Code插件访问到特定的目录，这个特定的配置文件就会发挥作用。在下面这个例子中，在git-graph插件（下载安装次数已经超过500万）中会从VS Code的workspace setting配置文件中读取git.path这个变量的值，然后拿去启动特定的子进程。

假设有一个（恶意部署的）配置文件，里面包含了下面这样的键值对，那么git-graph插件就会去运行a-shell-script.sh脚本，招致攻击！

这样的例子在论文中还有好几个，它们的共同特征就是数据会从不可信的输入到达shell，或者被eval这种危险的函数当作参数来执行，以及可能被写入到本地文件中去。下面四个表分别展示了在分析过的VS Code插件中，这些危险的sink可能会被四类source影响到的情况。

总结一下，这篇论文就是通过定义了特定的CodeQL规则，来检查VS Code插件中的不可信数据是否存在危险的传播（这个技术内核并不算新，可以回溯到21世纪初两个经典的工作——TaintBochs和TaintCheck），然后发现了一堆问题，揭示了相关安全风险！大家只要实验做得扎实，不需要老是想着发明高超的技术，按照这个思路也可以写出高水平论文哦。

---

论文：https://www.ndss-symposium.org/wp-content/uploads/2024-73-paper.pdf
数据集和CodeQL规则：https://github.com/s3c2/UntrustIDE

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2024-02-21 危险的VS Code插件