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