标签: 分析工具

作者： Shawn Prestridge ， IAR 资深现场应用工程师 / 美国 FAE 团队负责人 安全 一直都 是一个非常热门的话题 ， 似乎每 周 都会听到这样的消息：某某公司如何被入侵，数百万用户的数据被泄露。 我们看到这么多的安全问题，部分原因 在于 我们对待安全的方式： 安全 性 通常被认为是事后 考虑 的 问题 ， 是在 开发结束时 才 添加到 设备上的东西。然而，复杂的系统，尤其是嵌入式系统，有一个很大的攻击面，这让攻击者有机可乘，能够在 “ 盔甲 ” 上找到 破绽 。如果你 去 研究大部分黑客试图 入 侵系统的方式，你很快就会发现，在他们的武器库中，他们最喜欢的 手段就 是寻找和利用设备的软件漏洞。 如果软件漏洞是黑客 所利 用的 入口 ，那么我们就需要提高 自己 的代码质量来解决这个问题。但是，这个问题有多 严重 ，我们能做什么来解决它呢？ 代码漏洞容易成为黑客的目标 代码质量糟糕实际上是一个普遍 存在 的问题，而且有相当多的证据支持这样的说法：糟糕的 编码 直接导致了漏洞。虽然许多软件工程专家多年来一直在宣扬这一点，但人们第一次真正意识到这一点也许是在 2001 年，当时红色代码 （ Code Red ） 蠕虫 对 微软的互联网信息服务（ IIS ） 施加了 缓冲区溢出攻击 。 虽然第一个有记载的缓冲区溢出攻击发生在 1988 年，针对的是 Unix 的 finger 指令，但对普通人的影响十分有限，因此没有上头条新闻。 由于红色代码造成了大规模的互联网减速，并在新闻 报道 中铺天盖地 的传播 ，突然间，我们随处都能看到缓冲区溢出攻击的增加 ，看上去 安全研究人员和黑客都在各种系统 （ 包括嵌入式系统 ） 中到处 寻 找这些漏洞。利用缓冲区溢出攻击，黑客可以在受影响的系统上运行他们想要 运行 的任何代码，其目标是使用固定长度的缓冲区来保存文本或数据的一切代码。黑客将缓冲区空间填 充 到最大，然后在合法缓冲区空间的末端写下可执行代码。 然后， 被攻击的系统就会执行缓冲区末端的代码，在许多情况下， 这就可以使 攻击者为所欲为了。 这种类型的攻击之所以 成为紧急事件 ，是因为 当时 检查和执行缓冲区限制的编码并不普遍，但 现在 许多编码标准，如 mitre.org 的 通用缺陷列表 （ Common Weakness Enumeration ， C WE ） ，都建议检查缓冲区 是否存在 这种类型的漏洞。 遗憾 的是，开发 人员 在 编 写代码时普遍都不去 寻 找 这个 问题 ， 通常需要代码分析工具来发现这些问题，这样开发 人员 才会意识到问题的存在并加以修复。像这样一个简单的代码质量改进，就可以消除黑客最常使用的 手段 之一，从而大大提高代码的安全性。因此，检查并执行 代 码中 的 缓冲区长度，这样的编码才是好编码 。 不仅仅是缓冲区溢出 然而，问题不仅仅 在于 缓冲区溢出 ， 这 实际上是一个系统性问题， 草率 的编码 通常会 导致无数的安全漏洞，而黑客可以利用这些漏洞来入侵系统。美国软件工程学会（ SEI ）发表的一篇论文 将这一点 说得非常清楚： “ ...... 质量性能指标为确定高质量产品 、 预测安全 和 保障结果提供了依据。 通用缺陷列表 （ CWE ） 中的许多内容 ，如编程语言结构的不当使用 、 缓冲区溢出 、 验证输入值失败 等 ，都可能与低质量的编码和开发过程有关。提高代码质量是解决一些软件安全问题的必要条件。 ” 该 论文还指出，因为许多安全问题是 由 软件漏洞引起的 ，因此 可以像 处理 更普通的编码漏洞一样 处理安全问题 ，您可以应用传统的质量保证技术来帮助解决至少一 部分 安全问题。 既然正常的软件质量保证过程可以让我们估计系统中剩余的漏洞数量，那么 可以 对安全漏洞 做同 样的 事情 吗？虽然 SEI 没有确认代码质量和安全 性 之间的数学关系，但他们确实指出， 1% 到 5% 的软件漏洞是安全漏洞，并继续指出，他们的证据表明当安全漏洞被追踪时，他们可以准确地估计系统中的代码质量水平。 这最终表明，代码质量是安全的必要条件（但不是充分条件），真正 让“安全 性 可以被视为 开 发结束 时才 添加到 设备 上 的东西” 这一概念不攻自破。相反，安全 性 必须贯穿项目的 DNA ，从设计到编码，一直到生产。 编码标准 可提供 很大的帮助 许多最常见的安全漏洞都在 诸 如 mitre.org 的 通用缺陷列表等 编码标准中得到了解决，并指出了需要关注的其他 方面 ， 如除 零 错误 、数据注入、循环不规则、空指针利 用和 字符串解析错误 。 MISRA C 和 MISRA C++ 还提倡编码的安全性和可靠性，以防止安全漏洞渗入你的代码。虽然这些 编码标准 可以捕捉到许多常 见 的漏洞，但开发人员在编写代码时必须 考虑 得更 长 远：黑客 是 如何利用我刚刚 编 写的代码的？漏洞在哪里？我是否对输入会是什么样子以及输出会如何使用做了假设？一个好的经验法则是，如果你在做假设，那么这些假设应该变成代码，以确保你所期待的东西实际上 就 是你所要得到的。如果你不这样做，那么黑客就会 出手了 。 但是开源软件呢？在设计中使用开源组件的典型论点 依赖 于 “ 已 在使用中被 证明” （ proven in use ） 的论点：这么多人使用它，它一定是好的。 SEI 的 同一 篇论文 对 于这个问题 也有一些阐 述： “ 除了免费之外 ， 开源 所宣扬 的好处之一，就是认为 ‘ 有很多人关注源代码意味着安全问题可以很快被发现，任何人都可以修复漏洞 ， 不需要依赖供应商 ’ 。然而，现实情况是，如果没能有纪律地、一致地把 关注点 放在消除漏洞上，安全漏洞和其他漏洞将出现在代码中。 ” 换句话说， SEI 认为， “ 已 在 使用中被 证明”的论点 毫无意义， 并且在 将质量保证应用 于 开源代码 时 ， 会 让人想起 Anybody 、 Somebody 、 Nobody 和 Everybody 的故事。此外，你的测试并不足以证明代码是令人满意的。 SEI 表示 ，像 CWE 这样的代码质量标准可以发现你代码中的问题，而这些问题 往往 不会在标准测试中被发现，通常只有在黑客利用漏洞时才会被发现。 为了证明这一点， 2020 年 5 月，普 渡大学 的研究人员展示了 在 Linux 、 macOS 、 Windows 和 FreeBSD 中使用的开源 USB 堆栈的 26 个漏洞。 所以， 谈 及 安全 性时 ，代码质量是关键， 并且 所有 代码都很重要。 代码分析工具有助于遵守标准 在解决代码质量问题上，我们可以做些什么来提高 自己 应用程序的安全性呢？简单的答案 就 是使用代码分析工具，这些工具有两种基本类型：静态分析 工具 和运行时（或动态）分析 工具 ，静态分析只查看应用程序的源代码，而运行时分析则是对代码进行检测，寻找空指针和数据注入方法等漏洞。 I AR 可以同时提供这两种工具，包括静态分析工具 I AR C-STAT 和运行时分析工具 I AR C-RUN ，它们 都完全集成在 IAR Embedded Workbench 开发环境中。 高质量的代码分析工具包括对 CWE 、 MISRA 和 CERT C 的检查。 CERT C 是另外一 种 编码标准，旨在促进编码安全。这三个 规则集共同 构成了一个 优质组合， 有助于实现可提升 安全 性 的编码：一些 规则集 与其他规则 集有 重合 之处 ，但也提供了一些独特的功能， 可 以帮助确保你的代码具有高度的安全性。使用这些标准也有助于确保你 拥有最高 的代码质量，甚至可能发现代码中的一些潜在漏洞。 高质量的 代码就是 安全的代码 保证代码质量才能确保代码安全。不要把代码质量的责任推给别人，因为别人的漏洞很可能 给 你 带来 安全 性方面的 噩梦。但希望还是有的，因为代码分析工具可以 帮助 你在漏洞找麻烦之前迅速发现问题。通往安全的道路总是要经过代码质量这一关口。 参考资料 https://www.caida.org/research/security/code-red/ https://malware.wikia.org/wiki/Buffer_overflow https://cwe.mitre.org/data/definitions/121.html https://resources.sei.cmu.edu/asset_files/TechnicalNote/2014_004_001_428597.pdf https://www.techradar.com/news/usb-systems-may-have-some-serious-security-flaws-especially-on-linux