AI 技能AI 插件应用安全网络安全AI 评测【免费下载链接】skillsTrail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows项目地址https://gitcode.com/gh_mirrors/skills8/skills点击查看免费下载导读本文聚焦 Trail of Bits 开源仓库skills8/skills中rust-review插件的一个关键检测模式——out-of-bounds-index-finderOOBIDX。它专门用于在安全 RustSafe Rust代码中识别vec[i]/arr[i]/slice[i]这类方括号索引语法下、索引值由攻击者输入控制而导致的越界 panic内存越界读取这类 panic 在服务端场景下可直接转化为拒绝服务DoS。读完本文你将掌握 OOBIDX 的完整检测判定规则Gates、明确的误报FP排除条件、标准修复方案以及该模式在rust-review并行审计流水线中的实际运行机制——包括它所属的 panic-dos 集群、worker 覆盖率门禁和 FP严重性判定阶段的落地细节。检测模式定位OOBIDX 在 rust-review 中的角色out-of-bounds-index-finder.md位于 prompts/general 目录是rust-review插件中负责检测整数索引越界 panic的专用 finder 提示词。从 manifest.json 可以看到它被注册在panic-dos集群中对应的 bug class 为out-of-bounds-indexFinding ID 前缀为OOBIDX{ bug_class: out-of-bounds-index, prefix: OOBIDX, prompt: prompts/general/out-of-bounds-index-finder.md }该集群的gate为always意味着无论代码库是否包含unsafe、FFI 或并发代码panic-dos 集群都会运行。这一点在 README.md 中有明确说明即使是纯 Safe Rust crate仍然存在 panic 导致的 DoS 风险因此 panic-dos 属于 always-on 集群。与同类检测模式的边界划分panic-dos 集群内包含七个 passOOBIDX 只负责整数索引越界这一种形状。集群提示词 panic-dos.md 的 Deconfliction 章节明确划定了职责边界OOBIDX拥有Vec/[T]/ 数组的整数索引越界v[i]且i v.len()STRSLICEstr-slice-boundary负责str的区间切片 /split_at/truncate中字节索引落在 UTF-8 字符边界之外导致的 panic——这类 panic 即使在索引范围内也会触发ARITHOFLarithmetic-overflow负责整数运算溢出与除零 panicRESEXHAUST负责资源耗尽无限循环、O(n²)、无上限Vec::reserve——这一类比 panic 更隐蔽进程可能不 panic 而只是挂起。理解这个边界是正确使用 OOBIDX 的前提同一个漏洞根因只能归属到最具体匹配的 pass 下避免跨类别重复报告。OOBIDX 的核心判定规则Gates原文档定义了三条必须同时满足的检测门Gatesworker 在搜索时严格按此判定是否成立一个OOBIDXfindingGate 1方括号索引的目标容器索引表达式必须作用在以下容器之一上且该容器在越界时会发生 panicVecT[T]切片引用[T; N]定长数组任何实现了Indextrait 且越界会 panic 的类型Rust 的Indextrait 语义决定了方括号语法v[i]等价于*v.index(i)而Vec/ 切片的标准实现会在i len时调用panic!。因此这条 gate 识别的是会 panic 的索引表达式而不是get_unchecked这类不检查边界的 unsafe 变体——后者由 memory-safety 集群中的buffer-overflow-unsafeBOF模式负责见 buffer-overflow-unsafe-finder.md该文件明确说明get_unchecked(_mut)、copy_nonoverlapping、ptr::write以及裸指针.offset()/.add()/.sub()属于 BOF 而非 OOBIDX。Gate 2索引值来源于不可信输入索引整数必须派生自不受信任的输入。这要求 worker 做污点追踪taint trace从外部输入源网络报文、HTTP 头部、CLI 参数、反序列化数据、FFI 输入等追踪到索引计算点。集群提示词 panic-dos.md 给出了 Phase C 的种子搜索模式其中专门包含rg seed: \[\s*\w\s*\] # bracket indexing再配合 Phase 1 建立的入口点清单network、files、CLI、IPC、serde反序列化、FFI 输入worker 对命中方括号索引的候选点逐一Read验证确认索引值的数据流源头。Gate 3缺少可达路径上的边界检查必须满足二选一可达路径上没有任何if idx v.len()的前置检查或者边界检查的算术本身存在溢出风险例如if idx v.len() - 1且v.len()可能为 0导致usize下溢使检查恒真。这条 gate 是整个检测模式的核心价值很多真实漏洞并非缺少检查而是检查写得不正确。从 rust-review-worker.md 的 Rationalizations to reject 部分可以看出worker 被明确要求验证上游校验确实存在且可达不能轻信// SAFETY:注释或上游已校验的假设。误报排除清单FPs原文档明确了三类不构成 finding 的情况worker 在命中候选点后必须先套用这些排除规则索引是常量v[3]这种编译期确定的常量索引只要常量值静态小于容器长度不可能越界紧随.get(idx).is_some()检查调用方已经通过Option显式验证了索引有效性再索引是安全的定长数组且索引受const N约束容器静态是[T; N]且索引上限由常量N限定越界不可能发生。值得注意的是这条 FP 清单与 BOF 模式的 FP 规则互为补充见 buffer-overflow-unsafe-finder.mdBOF 的 FP 条件是索引是静态小于数组长度的硬编码常量或者边界检查使用了checked_*/saturating_*算术且与.len()比较。两条规则共同构成对看似危险、实则安全模式的完整过滤。标准修复方案Patch原文档给出的推荐修复是v.get(i).ok_or(Error::OutOfRange)?将v[i]替换为v.get(i)把panic 语义改写为返回OptionT语义配合ok_or(...)?将失败路径显式转换为错误传播。这个修复的深层原理是get是Index的安全替代 API越界时返回None而非 panic错误类型Error::OutOfRange需要在使用方自定义枚举中定义属于应用层错误处理设计在服务端场景下panic 会终止线程panic abort下直接终止进程而错误传播允许上层优雅处理并继续服务。从 fp-judge 的严重性分级表可以看到REMOTE威胁模型下通过可达的unwrap/panic!/assert!/算术溢出在攻击者输入上实现的远程 DoS被评为HIGH——这直接印证了修复 OOBIDX 类问题的必要性它不只是代码风格问题而是真实的服务可用性风险。实际运行机制OOBIDX 如何在审计流水线中落地归属 panic-dos 集群的 pass 顺序panic-dos.md 规定七个 pass 按 manifest 顺序执行OOBIDX排在第五位第 5 pass。cluster 先做 Phase A 的 profile 门控检查overflow-checks、Phase B 的资源耗尽清单、Phase C 的 panic 清单OOBIDX 在 Phase C 的方括号索引种子上展开。覆盖率门禁每条 pass 必须留痕worker 完成每个 pass 后必须在覆盖率文件中为OOBIDX这一行写结果——filed: OOBIDX-001或cleared (no bracket indexing on untrusted indices)之类的短语见 rust-review-worker.md。skipped:不是合法结果任何未执行的 pass 都会被validate_artifacts.py判定为 coverage failure。这意味着每次审计中 OOBIDX 模式都必然被搜索并留痕不会因 worker 主观判断而被悄悄跳过。从 finding 到最终报告以OOBIDX前缀命名的 finding 文件OOBIDX-001.md等写入{output_dir}/findings/遵循 worker 协议规定的七段式正文结构Description、Code、Data flow、Reachability trace、Impact、Mitigations checked、Recommendation。之后经过 dedup-judge 去重、fp-judge 判定fp_verdictTRUE_POSITIVE / LIKELY_TP / LIKELY_FP / FALSE_POSITIVE / OUT_OF_SCOPE与严重性分级最终进入 REPORT.md 和 REPORT.sarif。在审计中应用 OOBIDX 的实战要点结合 SKILL.md 的编排流程实际调用该检测能力时需注意威胁模型决定严重性REMOTE下远程可触发的越界索引 panic 是 HIGH远程 DoSLOCAL_UNPRIVILEGED下若未跨越权限边界则可能是 LIKELY_FP。fp-judge 的严重性是相对的同一 bug 在不同威胁模型下分级不同用rg而非裸grep执行种子正则finder 提示词中的种子模式使用 ripgrep 语法\s、\d、\b某些grep实现会静默将\s当作字面量处理返回空结果造成虚假的cleared。SKILL.md 明确要求 Bash 型 agent 用rg缺失时降级为grep -E POSIX 字符类\s→[[:space:]]、\d→[[:digit:]]、丢弃\b不因severity_filter而丢弃 findingseverity_filter只影响最终 REPORT 的渲染不影响磁盘上存在的 finding。worker 必须提交每一个确认的 bug哪怕是低严重性——OOBIDX 类问题同理。参考与延伸阅读检测模式本体out-of-bounds-index-finder.md所属集群与去冲突规则panic-dos.md集群注册与 pass 声明manifest.jsonworker 执行协议与覆盖率门禁rust-review-worker.mdFP 判定与严重性分级rust-review-fp-judge.md插件总览与集群架构README.md、SKILL.md赞分享AI 技能AI 插件应用安全网络安全AI 评测【免费下载链接】skillsTrail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows项目地址https://gitcode.com/gh_mirrors/skills8/skills点击查看免费下载相关推荐Rust 浮点边界安全审计解析 rust-review 的 FLOATEDGE 检测器与 NaN/Inf 攻击面Rust 浮点边界安全审计解析 rust review 的 FLOATEDGE 检测器与 NaN/Inf 攻击面 导读 本文围绕 Trail of BitsAI 技能AI 插件应用安全网络安全AI 评测Rust FFI 跨语言边界安全审计实战深入 rust-review 的 ffi-cross-language 漏洞簇Rust FFI 跨语言边界安全审计实战深入 rust review 的 ffi cross language 漏洞簇 Rust 与 C/C 等其他语言通AI 技能AI 插件应用安全网络安全AI 评测Rust 安全审计中的 UNWRAP 检测识别不可信输入上的 unwrap/expect 引起的 panic DoSRust 安全审计中的 UNWRAP 检测识别不可信输入上的 unwrap / expect 引起的 panic DoS 导读 本文介绍 Trail of BAI 技能AI 插件应用安全网络安全AI 评测上一篇终极PyMCubes入门教程从安装到生成第一个3D模型下一篇ksync 高级配置自定义同步规则、忽略文件与性能优化技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
AI 技能AI 插件应用安全网络安全AI 评测【免费下载链接】skillsTrail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows项目地址https://gitcode.com/gh_mirrors/skills8/skills点击查看免费下载导读本文聚焦 Trail of Bits 开源仓库skills8/skills中rust-review插件的一个关键检测模式——out-of-bounds-index-finderOOBIDX。它专门用于在安全 RustSafe Rust代码中识别vec[i]/arr[i]/slice[i]这类方括号索引语法下、索引值由攻击者输入控制而导致的越界 panic内存越界读取这类 panic 在服务端场景下可直接转化为拒绝服务DoS。读完本文你将掌握 OOBIDX 的完整检测判定规则Gates、明确的误报FP排除条件、标准修复方案以及该模式在rust-review并行审计流水线中的实际运行机制——包括它所属的 panic-dos 集群、worker 覆盖率门禁和 FP严重性判定阶段的落地细节。检测模式定位OOBIDX 在 rust-review 中的角色out-of-bounds-index-finder.md位于 prompts/general 目录是rust-review插件中负责检测整数索引越界 panic的专用 finder 提示词。从 manifest.json 可以看到它被注册在panic-dos集群中对应的 bug class 为out-of-bounds-indexFinding ID 前缀为OOBIDX{ bug_class: out-of-bounds-index, prefix: OOBIDX, prompt: prompts/general/out-of-bounds-index-finder.md }该集群的gate为always意味着无论代码库是否包含unsafe、FFI 或并发代码panic-dos 集群都会运行。这一点在 README.md 中有明确说明即使是纯 Safe Rust crate仍然存在 panic 导致的 DoS 风险因此 panic-dos 属于 always-on 集群。与同类检测模式的边界划分panic-dos 集群内包含七个 passOOBIDX 只负责整数索引越界这一种形状。集群提示词 panic-dos.md 的 Deconfliction 章节明确划定了职责边界OOBIDX拥有Vec/[T]/ 数组的整数索引越界v[i]且i v.len()STRSLICEstr-slice-boundary负责str的区间切片 /split_at/truncate中字节索引落在 UTF-8 字符边界之外导致的 panic——这类 panic 即使在索引范围内也会触发ARITHOFLarithmetic-overflow负责整数运算溢出与除零 panicRESEXHAUST负责资源耗尽无限循环、O(n²)、无上限Vec::reserve——这一类比 panic 更隐蔽进程可能不 panic 而只是挂起。理解这个边界是正确使用 OOBIDX 的前提同一个漏洞根因只能归属到最具体匹配的 pass 下避免跨类别重复报告。OOBIDX 的核心判定规则Gates原文档定义了三条必须同时满足的检测门Gatesworker 在搜索时严格按此判定是否成立一个OOBIDXfindingGate 1方括号索引的目标容器索引表达式必须作用在以下容器之一上且该容器在越界时会发生 panicVecT[T]切片引用[T; N]定长数组任何实现了Indextrait 且越界会 panic 的类型Rust 的Indextrait 语义决定了方括号语法v[i]等价于*v.index(i)而Vec/ 切片的标准实现会在i len时调用panic!。因此这条 gate 识别的是会 panic 的索引表达式而不是get_unchecked这类不检查边界的 unsafe 变体——后者由 memory-safety 集群中的buffer-overflow-unsafeBOF模式负责见 buffer-overflow-unsafe-finder.md该文件明确说明get_unchecked(_mut)、copy_nonoverlapping、ptr::write以及裸指针.offset()/.add()/.sub()属于 BOF 而非 OOBIDX。Gate 2索引值来源于不可信输入索引整数必须派生自不受信任的输入。这要求 worker 做污点追踪taint trace从外部输入源网络报文、HTTP 头部、CLI 参数、反序列化数据、FFI 输入等追踪到索引计算点。集群提示词 panic-dos.md 给出了 Phase C 的种子搜索模式其中专门包含rg seed: \[\s*\w\s*\] # bracket indexing再配合 Phase 1 建立的入口点清单network、files、CLI、IPC、serde反序列化、FFI 输入worker 对命中方括号索引的候选点逐一Read验证确认索引值的数据流源头。Gate 3缺少可达路径上的边界检查必须满足二选一可达路径上没有任何if idx v.len()的前置检查或者边界检查的算术本身存在溢出风险例如if idx v.len() - 1且v.len()可能为 0导致usize下溢使检查恒真。这条 gate 是整个检测模式的核心价值很多真实漏洞并非缺少检查而是检查写得不正确。从 rust-review-worker.md 的 Rationalizations to reject 部分可以看出worker 被明确要求验证上游校验确实存在且可达不能轻信// SAFETY:注释或上游已校验的假设。误报排除清单FPs原文档明确了三类不构成 finding 的情况worker 在命中候选点后必须先套用这些排除规则索引是常量v[3]这种编译期确定的常量索引只要常量值静态小于容器长度不可能越界紧随.get(idx).is_some()检查调用方已经通过Option显式验证了索引有效性再索引是安全的定长数组且索引受const N约束容器静态是[T; N]且索引上限由常量N限定越界不可能发生。值得注意的是这条 FP 清单与 BOF 模式的 FP 规则互为补充见 buffer-overflow-unsafe-finder.mdBOF 的 FP 条件是索引是静态小于数组长度的硬编码常量或者边界检查使用了checked_*/saturating_*算术且与.len()比较。两条规则共同构成对看似危险、实则安全模式的完整过滤。标准修复方案Patch原文档给出的推荐修复是v.get(i).ok_or(Error::OutOfRange)?将v[i]替换为v.get(i)把panic 语义改写为返回OptionT语义配合ok_or(...)?将失败路径显式转换为错误传播。这个修复的深层原理是get是Index的安全替代 API越界时返回None而非 panic错误类型Error::OutOfRange需要在使用方自定义枚举中定义属于应用层错误处理设计在服务端场景下panic 会终止线程panic abort下直接终止进程而错误传播允许上层优雅处理并继续服务。从 fp-judge 的严重性分级表可以看到REMOTE威胁模型下通过可达的unwrap/panic!/assert!/算术溢出在攻击者输入上实现的远程 DoS被评为HIGH——这直接印证了修复 OOBIDX 类问题的必要性它不只是代码风格问题而是真实的服务可用性风险。实际运行机制OOBIDX 如何在审计流水线中落地归属 panic-dos 集群的 pass 顺序panic-dos.md 规定七个 pass 按 manifest 顺序执行OOBIDX排在第五位第 5 pass。cluster 先做 Phase A 的 profile 门控检查overflow-checks、Phase B 的资源耗尽清单、Phase C 的 panic 清单OOBIDX 在 Phase C 的方括号索引种子上展开。覆盖率门禁每条 pass 必须留痕worker 完成每个 pass 后必须在覆盖率文件中为OOBIDX这一行写结果——filed: OOBIDX-001或cleared (no bracket indexing on untrusted indices)之类的短语见 rust-review-worker.md。skipped:不是合法结果任何未执行的 pass 都会被validate_artifacts.py判定为 coverage failure。这意味着每次审计中 OOBIDX 模式都必然被搜索并留痕不会因 worker 主观判断而被悄悄跳过。从 finding 到最终报告以OOBIDX前缀命名的 finding 文件OOBIDX-001.md等写入{output_dir}/findings/遵循 worker 协议规定的七段式正文结构Description、Code、Data flow、Reachability trace、Impact、Mitigations checked、Recommendation。之后经过 dedup-judge 去重、fp-judge 判定fp_verdictTRUE_POSITIVE / LIKELY_TP / LIKELY_FP / FALSE_POSITIVE / OUT_OF_SCOPE与严重性分级最终进入 REPORT.md 和 REPORT.sarif。在审计中应用 OOBIDX 的实战要点结合 SKILL.md 的编排流程实际调用该检测能力时需注意威胁模型决定严重性REMOTE下远程可触发的越界索引 panic 是 HIGH远程 DoSLOCAL_UNPRIVILEGED下若未跨越权限边界则可能是 LIKELY_FP。fp-judge 的严重性是相对的同一 bug 在不同威胁模型下分级不同用rg而非裸grep执行种子正则finder 提示词中的种子模式使用 ripgrep 语法\s、\d、\b某些grep实现会静默将\s当作字面量处理返回空结果造成虚假的cleared。SKILL.md 明确要求 Bash 型 agent 用rg缺失时降级为grep -E POSIX 字符类\s→[[:space:]]、\d→[[:digit:]]、丢弃\b不因severity_filter而丢弃 findingseverity_filter只影响最终 REPORT 的渲染不影响磁盘上存在的 finding。worker 必须提交每一个确认的 bug哪怕是低严重性——OOBIDX 类问题同理。参考与延伸阅读检测模式本体out-of-bounds-index-finder.md所属集群与去冲突规则panic-dos.md集群注册与 pass 声明manifest.jsonworker 执行协议与覆盖率门禁rust-review-worker.mdFP 判定与严重性分级rust-review-fp-judge.md插件总览与集群架构README.md、SKILL.md赞分享AI 技能AI 插件应用安全网络安全AI 评测【免费下载链接】skillsTrail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows项目地址https://gitcode.com/gh_mirrors/skills8/skills点击查看免费下载相关推荐Rust 浮点边界安全审计解析 rust-review 的 FLOATEDGE 检测器与 NaN/Inf 攻击面Rust 浮点边界安全审计解析 rust review 的 FLOATEDGE 检测器与 NaN/Inf 攻击面 导读 本文围绕 Trail of BitsAI 技能AI 插件应用安全网络安全AI 评测Rust FFI 跨语言边界安全审计实战深入 rust-review 的 ffi-cross-language 漏洞簇Rust FFI 跨语言边界安全审计实战深入 rust review 的 ffi cross language 漏洞簇 Rust 与 C/C 等其他语言通AI 技能AI 插件应用安全网络安全AI 评测Rust 安全审计中的 UNWRAP 检测识别不可信输入上的 unwrap/expect 引起的 panic DoSRust 安全审计中的 UNWRAP 检测识别不可信输入上的 unwrap / expect 引起的 panic DoS 导读 本文介绍 Trail of BAI 技能AI 插件应用安全网络安全AI 评测上一篇终极PyMCubes入门教程从安装到生成第一个3D模型下一篇ksync 高级配置自定义同步规则、忽略文件与性能优化技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
