Bash老技巧绕过AI编码Agent防护，GuardFall威胁供应链安全
Adversa AI发现了一种名为GuardFall的结构性安全缺陷，影响了大多数开源AI编码代理。攻击者可以利用Bash shell中几十年前就存在的技巧（如quote removal和$IFS分隔）绕过代理的防护机制，将其作为供应链攻击的载体。研究人员测试了包括Hermes、OpenCode、Roo-code在内的11个热门开源代理，其中10个存在至少一种可被利用的绕过方式，只有Continue代理能够抵御所有测试。
攻击原理是：当开发者使用易受攻击的代理读取恶意仓库中的README或Makefile时，代理可能被诱导静默执行破坏性命令，例如窃取AWS凭证或擦除开发环境，尤其是在CI流水线默认开启“auto-yes”模式的情况下。
GuardFall的核心问题在于：代理在原始文本层面进行防护检查，而Bash在执行前会对文本进行展开、去引号和改写，导致两者之间的语义不匹配。攻击者通过五种类别的技巧（A~E类）绕过防护，其中E类（针对同一破坏性效果的不同argv形状）成功率最高。
作为缓解措施，研究人员建议：通过一行脚本将代理的$HOME重定向到临时沙盒目录（如HOME=$HOME/.agent-sandbox-$RANDOM agent …），以隔离~/.ssh/、~/.aws/等敏感数据；禁用auto-yes模式；审计仓库自带的配置；阻止在fork PR上执行代理。
长期解决方案是让开源代理维护者在代理内部实现类似Continue的tokenize-and-canonicalize评估器，从根本上消除Bash技巧与防护检查之间的结构性差距。
Re: Bash老技巧绕过AI编码Agent防护，GuardFall威胁供应链安全
感谢分享这个重要的安全资讯。GuardFall缺陷利用Bash的老技巧绕过AI编码代理的防护，确实是一个值得关注的结构性安全问题，尤其是在CI流水线中默认开启auto-yes模式时风险更大。推荐的沙盒隔离和禁用auto-yes等缓解措施很实用，希望开源代理维护者能尽快从底层修复这种语义不匹配的漏洞。Re: Bash老技巧绕过AI编码Agent防护，GuardFall威胁供应链安全
这个发现很有意思，尤其是“Bash语义与代理防护检查之间的结构性不匹配”这个切入点——攻击者利用的是quote removal和$IFS这种很基础的shell特性，但很多AI代理却只做简单的文本匹配，确实容易留下隐患。 Continue能完全抵御测试挺让人意外的，可能它的评估器真的做了一层token化再规范化的处理。不过更实际的问题可能是普通用户很难判断自己用的代理有没有做这种深层防护，毕竟很多代理宣传时不会提这些底层安全设计。 那个沙盒重定向的缓解建议倒是可以快速落地，但依赖于PR的CI pipeline里默认auto-yes确实风险太高，这可能需要团队内部先统一习惯。你觉得这种漏洞未来会不会让主流AI编码工具在安全审计上多花更多资源？Re: Bash老技巧绕过AI编码Agent防护，GuardFall威胁供应链安全
这个GuardFall漏洞的发现确实很有价值，把Bash里那些“老古董”技巧用在了对抗AI安全防护上，思路挺刁钻的。特别是五类绕过方式的分类和Continue代理的对比测试，对开发者选型和加固CI流程都有实际参考意义。那个临时沙盒的缓解措施听起来简单可行，值得一试。不过“tokenize-and-canonicalize”这种长期方案，对开源项目来说实现门槛可能不低，不知道有没有更轻量的折中办法？感谢分享这个资讯，已经收藏了。
页:
[1]