
实测 VS Code 扩展启动后台行为:GitLens 自动激活并建立外部连接
来源标题:What a Compromised VS Code Extension Could Do Before You Write a Line of Code
一项对 40 次 VS Code 启动的监测显示,Prettier 和 GitLens 都会在启动时自动激活,其中 GitLens 还会拉起辅助进程并建立对外网络连接。监测未发现两者被入侵的迹象,但凸显了编辑器扩展所掌握的信任程度。
以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。
我们监控了40次VS Code启动,观察扩展在后台做了什么。Prettier和GitLens都在启动时激活,GitLens还启动了辅助进程,并向外发起了连接。两者都没有被入侵的迹象,但它们都说明编辑器扩展掌握着多大的信任。
我们监控了40次VS Code启动,以了解扩展在后台能做什么。结果揭示了一个就藏在眼皮底下的重要安全考量:我们对开发环境中运行的软件寄予了多少信任。
我在Mac上打开VS Code,加载了一个小型Git仓库,然后就没再碰编辑器。
没有终端命令,没有编辑,没有与任何扩展交互。
启动几秒后,GitLens激活了。接着出现了一个名为gk的进程,随后又跟了两个进程,名为gk_3_1_79。
进程监视器还记录到了与远程服务器建立的出站连接。
以下是实际跟踪记录的一小段摘录: 1234 23:06:04.188 GitLens activated: onStartupFinished 23:06:08.514 gk process observed 23:06:09.529 gk -> 172.67.68.156:443 ESTABLISHED 23:06:10.083 gk_3_1_79 -> 52.2.209.199:443 ESTABLISHED
这个仓库只有三次提交和几个小文件。我并没有要求GitLens做任何事。
然而它已经在运行后台进程并连接远程服务了。
这一观察结果并不表明存在恶意行为。
GitLens是一款成熟的开发者工具,GitKraken CLI是其文档化集成生态的一部分。我们测试的另一个扩展Prettier也表现正常。在我们的实验中,两者都没有被入侵的证据。
这一点值得先说明。本次调查不是为了曝光流行扩展中的恶意行为。我们没有进行全面的安全审计,也不声称这两个扩展已获得独立的安全认证。
我感兴趣的是更根本的问题。
如果攻击者控制了一个已有权限在你的开发机器上执行代码的扩展,会发生什么?
想想一台典型开发者工作站上可访问的一切。
私有仓库、SSH密钥、环境文件、Git凭据、云认证、内部服务,有时还有生产基础设施。
我们花费大量时间保护这些资源免受恶意依赖和被入侵的软件包侵害。
与此同时,我们点几下就安装了编辑器扩展。
其中一些每次编辑器启动时都会激活。
我想确切了解这意味着什么。
VS Code扩展很容易被低估。
它们看起来只是小功能。一个格式化工具、一个Git集成、一个语法高亮器,或者某个添加便捷快捷键的东西。
但VS Code扩展系统支持的东西远不止界面定制。
根据微软的扩展运行时安全文档,在桌面扩展宿主中运行的扩展拥有与VS Code本身相同的操作系统权限。
视环境而定,这可能包括访问文件系统、网络连接以及启动外部程序的能力。
调试器需要启动和控制进程。语言服务器需要检查源文件。Git工具需要执行命令。有些扩展会与编辑器外部运行的服务集成。
问题在于,当行使这些权限的代码不再可信时会发生什么。
假设攻击者入侵了某个扩展发布者的账户或发布流水线。一个恶意更新到达了已安装该扩展的机器。
这段代码可能继承合法扩展的权限。
而且它可能在开发者做任何事之前就开始执行。
VS Code扩展在其package.json清单中定义激活事件。
这些事件告诉编辑器扩展应在何时启动。
有些扩展在你打开特定文件类型时激活。另一些在工作区包含特定文件时激活,或在用户调用命令时激活。
有一个激活事件特别值得注意: 12345 "activationEvents": [ "onStartupFinished"
VS Code在编辑器启动后的某个时刻发出onStartupFinished。
使用此事件的扩展可以在开发者未打开文件、未使用功能、未点击按钮的情况下开始执行。
我检查了十个常见VS Code扩展的清单。
Python、YAML和rust-analyzer使用了语言、工作区及其他条件激活事件,而没有该声明。
这是一个刻意选择的样本。它不能说明启动激活在整个VS Code Marketplace中有多普遍。
但它确实确立了扩展系统的一个重要特性。
扩展可以自动运行代码,而启动激活是平台中普通且文档化的一部分。
声明onStartupFinished并没有什么可疑之处。
但如果攻击者一旦控制了一个使用它的扩展,他们可能不需要开发者与被入侵的代码进行任何交互。
我想亲眼看到这些能力实际运作。
于是我围绕两个流行且合法的扩展搭建了一个小型实验:Prettier和GitLens。
Prettier格式化源代码。GitLens提供Git历史、注释、仓库洞察以及与GitKraken服务的集成。
两者都有充分理由在开发环境中运行代码。
实验在一台Apple Silicon Mac上进行,使用macOS 27.0和VS Code 1.144.x。
我在四种条件下测试了Prettier 12.4.0和GitLens 19.5.0:
每次会话运行90秒。一个Python脚本每0.5秒采样一次进程信息和已建立的TCP连接。
每次运行都使用隔离的用户数据和扩展目录。我常用的VS Code扩展和设置未被加载。
脚本记录了进程ID、常驻内存使用量、累计CPU时间和远程网络端点。
我还收集了扩展宿主日志,以核实每个扩展实际激活的时间。
(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。