AI编码助手Copilot和Cursor曝新漏洞:恶意规则文件潜藏风险

AI编码助手Copilot和Cursor曝出新漏洞,恶意规则文件可能导致代码中被植入后门或安全漏洞,开发者需加强审查,防范风险。

原文标题:Copilot 及 Cursor 等 AI 编码助手的新漏洞:通过规则文件注入恶意代码

原文作者:AI前线

冷月清谈:

Pillar Security的研究人员发现,GitHub Copilot和Cursor等AI编码助手存在安全漏洞,攻击者可以通过精心构造的恶意规则文件,在AI生成的代码中植入后门、漏洞或泄露敏感信息。这种攻击方法利用了规则文件中隐藏的Unicode字符和越狱代码,绕过安全检查,指示AI助手在生成的代码中添加恶意脚本。由于开发者社区共享规则文件,攻击者可以通过多种方式传播恶意文件。虽然Cursor和GitHub均表示用户有责任审查代码,但Pillar建议开发者应像审查可执行代码一样严格审查AI配置文件和生成的代码,并使用自动化工具检测可疑内容。

怜星夜思:

1、AI编码助手的规则文件共享机制是否需要更严格的安全审查和验证?
2、除了审查规则文件,开发者在使用AI编码助手时,还应该关注哪些安全问题?
3、如果AI编码助手生成的代码中包含漏洞,开发者应该承担怎样的责任?

原文内容

整理 | 华卫

近日,Pillar Security 的研究人员报告称,诸如 GitHub Copilot 和 Cursor 这类人工智能编码助手,可能会通过恶意规则配置文件的分发而被操控,从而生成包含后门程序、漏洞及其他安全问题的代码。

规则文件被人工智能编码代理用于在生成或编辑代码时指导其行为。例如,一个规则文件可能包含指令,让编码助手遵循特定的编码最佳实践、采用特定的格式,或者用特定的语言输出回复内容。

Pillar 的研究人员开发出了一种攻击技术,他们称之为“规则文件后门”。这种技术通过向规则文件中注入对人类用户不可见但人工智能代理可读的指令,将规则文件武器化。研究人员指出,像双向文本标记和零宽度连接符这类隐藏的 Unicode 字符,可被用于在用户界面以及 GitHub 的拉取请求中隐藏恶意指令。

规则配置通常在开发者社区中共享,并通过开源代码库进行分发,或者包含在项目模板里。因此,攻击者可以通过在论坛上分享恶意规则文件、在像 GitHub 这样的开源平台上发布该文件,或者通过向一个热门代码库发送拉取请求来注入恶意规则文件。一旦被篡改的规则文件被导入到 GitHub Copilot 或 Cursor 中,人工智能代理在协助受害者未来的编码项目时,就会读取并遵循攻击者的指令。

在 Pillar 展示的一个例子中,一个看似指示人工智能“遵循 HTML5 最佳实践”的规则文件包含了隐藏文本,这些隐藏文本中还有进一步的指令,要求在每个文件的末尾添加一个外部脚本。这个隐藏的提示还包括一段越狱代码,用于绕过潜在的安全检查,让人工智能确信添加该脚本对于保护项目安全是必要的,并且这是公司政策的一部分,此外还包含了指令,要求在对用户的任何回复中都不要提及添加了该脚本这件事。

Pillar 的研究人员发现,当被要求生成一个 HTML 页面时,GitHub Copilot 和 Cursor 都会遵循指令添加外部脚本,并且在这两个助手的自然语言回复中都没有提到添加了这个脚本。

研究人员称,“规则文件后门”还有可能被用于在生成的代码中引入安全漏洞,或者创建会泄露数据库凭证或 API 密钥等敏感信息的代码。

Pillar 在 2025 年 2 月向 Cursor 披露了这一漏洞利用情况,并在 2025 年 3 月向 GitHub 披露了相关情况。Cursor 表示,这个问题并非源于其平台的漏洞,管理风险是用户的责任。GitHub 也做出了类似回应,称用户有责任审查并接受由 Copilot 生成的代码和建议。

在 GitHub 2024 年“软件开发中的人工智能”调查中,约 97% 的受访者表示,他们在工作中及工作外都使用过生成式人工智能,这表明人工智能编码辅助在开发者中相当普遍。

Pillar 建议开发者审查他们使用的所有规则文件,检查是否存在诸如不可见的 Unicode 字符或不寻常格式等潜在的恶意注入情况,并像审查可执行代码一样严格审查人工智能配置文件。

研究人员表示,对于人工智能生成的代码也应该仔细审查,尤其是对于外部资源引用等意外添加的内容。自动化检测工具也有助于识别规则文件中的可疑内容,或者人工智能生成代码中存在被篡改的迹象。

参考链接:

https://www.scworld.com/news/how-ai-coding-assistants-could-be-compromised-via-rules-file

 直播预告

智能编码工具层出不穷,究竟怎么选、如何用?3 月 5 日 -28 日,InfoQ 极客传媒将发起「智能编码系列」直播,邀请阿里、百度、腾讯、字节、商汤、思码逸等企业一起在线 Coding,与所有开发者直观感受和评测数款国内外在线编码工具在企业真实生产场景中的表现。欢迎扫码或点击按钮一键预约直播、查看回放


今日荐文




图片
你也「在看」吗?👇

我觉得这事儿得分情况看。如果AI助手明确提示了代码可能存在风险,但开发者还是选择了忽略,那责任肯定在开发者。但如果AI助手没有任何提示,而且漏洞非常隐蔽,那可能就需要平台和开发者共同承担责任了。毕竟,AI助手也是平台提供的服务,平台也有义务保证其安全性。

除了规则文件本身,AI生成的代码也需要重点关注。不能完全信任AI,一定要进行代码审查,看看有没有潜在的漏洞或不符合规范的地方。特别是涉及敏感信息处理的部分,更要小心谨慎。

我觉得吧,这事儿不能完全指望平台。用户自己也要提高警惕,别随便下载来路不明的规则文件。就像装软件一样,先看清楚是不是官方渠道,多看看用户的评价。毕竟,安全意识才是最好的防火墙!

咱就说,心态要放平!AI是工具,不是保姆。别指望它能解决所有问题。关键还是要提升自己的安全技能,这样才能更好地驾驭AI,而不是被它牵着鼻子走。万一AI给你生成了一堆屎山代码,你还得自己擦屁股呢!

这个问题问得好!我个人觉得是必须的。现在很多开发者都依赖这些助手,但规则文件如果缺乏监管,就可能成为攻击的入口。想象一下,如果官方能对规则文件进行签名认证,或者引入类似应用商店的审核机制,就能大大提高安全性,杜绝恶意文件混入。

这绝对是个烫手山芋!我觉得责任肯定在开发者身上。毕竟,最终的代码是开发者提交的,你有义务保证代码的质量和安全。不能甩锅给AI,说“这代码是AI生成的,我不管”。

从安全工程的角度来看,应该将AI编码助手视为一个潜在的威胁源。可以采用威胁建模的方法,分析AI编码助手可能存在的安全风险,并采取相应的缓解措施。例如,限制AI编码助手访问敏感数据的权限,或者对AI生成的代码进行静态分析和动态测试。

从法律角度看,开发者作为代码的最终责任人,需要承担相应的法律责任。即使使用了AI编码助手,开发者仍然需要对代码的质量和安全负责。如果因为代码漏洞导致了损失,开发者可能需要承担赔偿责任。

从学术角度看,我认为可以借鉴软件供应链安全的思路,引入规则文件的“信任链”概念。每个规则文件的发布者都需要进行身份验证,并提供规则文件的数字签名。AI编码助手在使用规则文件时,可以验证其签名是否有效,以确保规则文件没有被篡改。此外,还可以建立一个规则文件的信誉系统,根据规则文件的使用情况和用户的反馈,对其进行评分,从而帮助开发者选择可信的规则文件。