GitHub 浏览器版 VSCode 现漏洞，研究人员短通知披露引发安全伦理争议
GitHub 浏览器版 VSCode 编辑器现严重漏洞，安全研究人员短通知披露引伦理争议
此次漏洞披露引发了关于安全研究人员对供应商的期望，以及他们应在漏洞公布前多久通知供应商的疑问。
一名研究人员表示，GitHub 基于浏览器的 VSCode 编辑器存在一个漏洞，在某些情况下可能导致开发者令牌被盗。本周，Ammar Askar 在博客中披露了这一问题，显然 GitHub 的所有者微软已经解决了该问题。但这也引发了关于 DevOps 安全的疑问，以及研究人员的指控，即由于微软不重视漏洞发现，他认为在公开披露所发现的漏洞前，只需给微软短时间通知是合理的。
首先是这个漏洞：github.com 的用户可能没有意识到，当他们访问任何仓库时，只需更改 URL 就可以切换到 github.dev 及其基于浏览器的 VSCode 版本。Askar 在博客中表示，因为浏览器版的 VSCode 功能相当强大。“你可以查看仓库中的所有文件（即使是私有仓库），可以发送拉取请求，甚至可以进行提交。”Enderle Group 的负责人、IT 顾问 Rob Enderle 也认同，以这种方式进入 VSCode 是“执行快速任务的极其有用的战术工具”。在任何 GitHub 仓库中，只需按下“.”键，你就能立即获得一个基于浏览器的 VS Code 界面，而无需在本地克隆数 GB 的数据。这非常适合快速进行 PR 审查、快速编辑文档，或者在不中断工作流程的情况下即时浏览代码。不过要记住，它完全在浏览器沙盒中运行，没有计算后端、没有终端，也无法执行代码。他补充说，对于任何繁重的任务或实际编译，开发者仍然需要本地工作站的原始计算能力，或者像 Codespaces 这样的完整云环境。
Askar 指出，问题在于 github.com 通过 POST 方式将 OAuth 令牌发送到 github.dev，从而实现了这一功能，该令牌允许它代表你与 GitHub 进行交互。“该令牌的作用范围并不局限于你所交互的特定仓库，这意味着它可以完全访问你有权限访问的其他所有仓库。”他在博客中写道，“这个令牌的存在，以及这个 Web 应用几乎运行着 VSCode 百万行 TypeScript 代码库的事实，使其成为任何研究 VSCode 漏洞的人的绝佳目标。”
Askar 称，威胁行为者可以使用 Jupyter notebook（一种用于创建和共享计算文档的 Web 应用程序）在仓库中安装扩展，该应用程序能够在跳过发布者信任检查的情况下安装恶意本地工作区扩展。在他的概念验证中，Askar 表示，一旦他的有效负载运行，新安装的扩展将获取 GitHub API 令牌，运行查询以获取开发者有权限访问的私有仓库，然后打印出回复和令牌。Askar 表示，VSCode 的桌面版本也存在此漏洞，不过更难利用，因为威胁行为者需要说服受害者克隆他们的仓库并打开包含 Webview 脚本有效负载的笔记本。“当然，”他补充道，“如果你（黑客）在 Webview 中有其他跨站脚本攻击（XSS），并且能让受害者打开，你实际上就可以在他们的计算机上实现远程代码执行（RCE）。”
他在一封电子邮件中表示，这个漏洞“极其严重。互联网上的任何网站都可能将你重定向到一个 github.dev 链接，这可能会为攻击者提供一个令牌，使其能够读取和修改你的代码仓库。如果有人能说服一个流行软件项目的维护者点击一个链接，他们就可以对该项目进行任何修改。”Enderle 表示，这意味着“我们必须开始以严格、隔离的零信任参数来对待开发者端点，因为显然我们不能依赖供应商的自满来保护我们”。GitGuardian 的首席开发者倡导者 Dwayne McDaniel 补充说，这个问题再次提醒我们，除非你确切知道链接会带你去哪里，否则永远不要点击任何链接。
短时间通知
事情变得复杂起来。由于之前向微软披露 VSCode 漏洞时经历不愉快（漏洞已修复，但 Askar 未得到认可），这次他只提前一小时通知 GitHub 他将公布这一新发现。微软采取了 Askar 所说的“权宜之计”修复措施，即在开发者在 Web VSCode 中打开笔记本时添加确认提示，并禁止通过命令跳过可信发布者要求。
伦理问题
Askar 的短时间通知引发了一个伦理问题：负责任的研究人员在公开披露漏洞之前，应该提前多久通知供应商？如今，大多数信息安全专家都认为必须提前通知，否则威胁行为者可能会迅速利用漏洞。不仅如此，如果不给予合理的通知，研究人员还可能损害自己的声誉。有经验的研究人员通常会给供应商至少 30 天的时间来创建和分发补丁。就供应商而言，他们通常会创建漏洞赏金计划，或与漏洞赏金计划合作，以奖励研究人员的工作。不幸的是，一些供应商并不总是认可研究人员的工作，或者低估漏洞可能造成的损害。事实上，上个月微软就与一位知名的网络安全研究人员就一起此类事件公开争吵。
权力失衡
当被问及对 Askar 最新发现的看法时，微软发言人表示：“我们重视安全研究社区在加强我们的产品、服务和更广泛的技术生态系统安全方面所发挥的关键作用。虽然独立研究人员自行决定何时以及如何公布他们的发现，但我们仍致力于迅速评估报告的问题，调动适当的工程和安全响应资源，并尽快提供缓解措施、指导和保护，以帮助保护我们的客户。”
Askar 告诉我们，在与软件供应商协调披露（CVD）和完全披露之间需要找到平衡。但他补充说，存在权力失衡的问题。“安全研究人员可能会在一个问题上投入无数小时，确保开发出良好的概念验证并提供重现问题的所有步骤。他们希望至少能得到对自己努力的认可，这可以用于提升他们的安全记录，或者在最好的情况下获得金钱赏金奖励。”然而，他补充道，“如果安全供应商不遵守他们的承诺，公开披露是安全研究人员为数不多的选择之一（如果他们不想搁置自己发现的漏洞或在黑市上出售它们）。这会迫使供应商公开承认安全问题，通常比任何私下沟通都能更快地解决问题。”Enderle 表示，这给企业带来了问题：“当供应商的官僚作风惩罚负责任的披露时，会疏远安全社区并导致零日漏洞公开披露，最终让企业客户承担后果。”
相关标签：GitHub、版本控制系统、软件开发、漏洞、安全、端点保护