...以及处理应对的办法

在这篇文章中，主要谈到了我对过去一年中软件设计和开发状态的一些观察，并且试图今年找到一个更加理性的成长路线。我的观点可能会局限于过去7年半的客户端软件安全性的经历。 尽管如此，对我来说也存在着广泛的趋势和关于行业未来走向的明显迹象。

我希望这篇文章对各种安全人员都有用：不仅是工程师，还有用户体验设计师和研究人员，项目/产品经理，业务经理以及运营人员。 无论如何，通向成功的路径都离不开这些人的帮助。 这篇文章比以往来说包含了更多的链接， 希望这会帮到你们。

下面大部分的关键问题就是复杂性。 硬件，软件，平台和生态系统通常过于复杂，我们的许多安全，隐私和滥用问题源于此。

加密网络发展的势头很好 ！ 此外， 将不安全的 web 源标记为不安全的，并将安全源标记为中立的，这两种方法都在向前发展。我们进步如此之快，令人感到十分舒适愉快，这让我对其他巨大的努力充满了希望(见下文)。一如既往地感谢 Let’s Encrypt 项目，以及朝着类似方向前进的其他浏览器!

虽然 内存破坏 漏洞仍广泛存在，但 iOS，Chrome 操作系统和 Chrome 证明了辅以有效的设计（减少权限），以及在实现上投入大量的精力( 真正实现减少权限， cluster fuzz 的漏洞挖掘，bug 的修复和快速部署)，确实可以显著提高（在那些利用不安全语言实现的项目里）利用内存破坏漏洞的成本。现如今利用内存破坏漏洞来攻克系统已远不再像上世纪 90 年代 或者 2000 年初那般简单。

iOS 继续具有出色的系统更新采用率 （参考另一篇文章），即使它是自愿的 - 这表明人们意识到了更新的价值。当然，人们不太可能根据安全本身做出选择。但 安全和隐私是 iOS 价值主张的关键部分，我认为至少有些客户会认识到这一点。

内存安全的编程语言占主导地位。此外，增长最快的语言是内存安全的，一些流行的语言甚至是类型安全的。 （有些人可能认为类型安全只是一个额外的好处，但对我来说，类型 是可靠和安全软件的关键组成部分。）甚至在系统软件中也有一些好消息，在此之前，系统软件是最不受挑战、也是最不值得关注的不安全领域：Go在那里很强大，而且Rust正好沿着（参见 Servo -- 浏览器引擎，CrOS VM -- Chrome OS 虚拟机监视器，Xi 编辑器, Fuchsia（操作系统） 的 部分 ）。虽然我们哀悼 Midori -- 操作系统)，但它仍然可以教给我们广泛适用的深刻教训。 （特别推荐 三种安全类型的故事 和 错误模型 两篇文章。）

内存标记是硬件的一种新（也是 旧有）的特性，可以帮助解决内存安全问题。人们正致力于在现代的系统上实现它 （论文）。我不认为它是一种尽可能地以系统方式修复 bug 的替代方案（理想情况下，在源语言中），但它具有提高安全性的巨大潜力。

静态检查器 - 编译器 - 和动态检查器（例如 Address Sanitizer 和 LLVM 的 sanitizers）在过去20年中取得了很大进展。曾经是最前沿的研究，而现在有现成的编译器免费提供，这真是太棒了! （从 Clang 或 GCC 中的 -Wall -Werror 开始，但我喜欢使用 -Weverything -Werror，只有少数例外情况，比如-Wno-padded 等。）

Chrome 正在对扩展平台进行一些结构性改进，这应该可以减少 生态系统中的一些最严重的滥用行为。

部分的软件行业 正在经历伦理和道德上的觉醒：

即便你不赞成上述这些立场，你仍然能发现一个好消息。那就是我们这一代的工程师正在超越以往的一种心态——“我能完成它，所以我做了；但是后果是什么呢？”。前几代人也需要做出类似的选择。

（我确实同意所有这些观点，我不会在为战争或警察设计的机器上工作，也不会在老大哥似的、经过审查的搜索引擎上工作。我支持为人人平等和公平待遇所作的努力。罢工是美好的一天，但这仅仅是个开始。还有很长的路要走。）

越来越多的人意识到并采用 通用第二因素身份验证 是一个好消息。( U2F 已被标准化为 WebAuthn，这比大多数安全人员希望的要复杂得多。期待 bug 的出现……)它提供的高程度的钓鱼抵抗至少和 HTTPS 提供的保护一样重要。网络钓鱼和账户接管一直是我们最大的问题之一，而网络认证可以对它们造成很大的影响。现在你可以在 Google、Facebook、Twitter、Dropbox、login.gov 等网站上使用它。

C++ 正在变得更加复杂和不安全：

在 C++ 日益复杂的问题上，C ++ 的创建者发现自己处于社区的另一端。 Stroustrup 将 C++ 日益增加的复杂性视为该语言的潜在致命风险。

新的安全API并不安全 (“不会修复”)

对于微优化的可疑目标，C 和 C++ 编译器继续利用未定义的行为 - 这是不应存在的行为。（John Regehr：“从开发人员的角度来看，一个非常聪明地识别并默默地摧毁 Type 3 函数的编译器变得非常邪恶。”）

C ++非常复杂，除了经典的 vanilla C 宏之外，经验丰富的程序员也无法找到一种通用的方法来查找静态数组的大小 。毕竟，也许简洁就是好的？

我无法列出所有的根本原因是不安全内存的漏洞报告，因为这些漏洞报告太多太多了。浏览高质量的漏洞分析报告是一种有趣的练习方式（Project Zero 博客 是我的最爱之一），并且计算到底在应用程序域中有多少错误。

（当然，如果您发现内存安全漏洞比应用程序域或其他的漏洞多的话，那也可能是由于研究人员的偏见。但我认为我们都同意内存破坏漏洞根本不应该存在，但现实是这种漏洞至今还是数量众多，并且经常可以利用。）

设计一种能够实现所有内存安全性，高性能和良好可用性的语言仍然非常困难。 Rust 编译器注意到并拒绝 C 和 C++ 编译器未注意到/无法注意/有目的地接受的安全错误。 这是 Rust 的功劳，但有的地方却很难学习。

编程语言研究社区的目标之一是证明程序是安全的。渐渐地，这种工作逐渐渗透到真正的语言中，人们可以真正使用这些语言来发布真正的软件。 使用学术工具的困难 在一定程度上是他们人数较少[“他们人数较少”翻译成“受众较少”更为准确]的自然结果，但有些困难是不可避免的：安全性的证明（proof of safety ）意味着需要证明（proof），这是博士都很难做到的。最终，软件工程社区将不得不逐渐地、越来越多地致力于满足这一标准。

显然，2018年是每个人都意识到 幽灵 & 熔断， 预兆（Foreshadow），L1TF，以及微观架构侧信道的概念。遗憾的是，共享资源比比皆是。当然，其他阻碍性能的安全问题（通常是由于极其复杂的原因）早就为人所知（参见 1，2）。虽然这些链接主要涉及英特尔架构系统，但没有理由认为（例如）ARM 天生就更安全。特别是，微架构侧信道问题是为最大性能而设计的自然结果 - 几乎每个芯片设计师都在尝试这样做，因为这几乎是每个客户都想要的。

相比利用漏洞攻击来说，滥用（恶意使用合法功能）会影响到更多人的生活。尽管黑客可能会产生意想不到的影响，比如政治后果或大规模数据泄露，但是你的朋友和家人感到悲伤的原因要平淡的多，也更难以解决：

正如预言所说，工作量证明（proof-of-work）继续不起作用。在未来的几十年里，形势将会越来越严峻，嗯，“挑战”，所有的计算系统都将不得不证明它们的价值，相对于它们所有的成本 —— 包括碳和电子垃圾。我们再也不能把这些当作外部因素来一笑置之了。工作量证明系统将继续无法显示出足够的成本价值，甚至可能成为监管的障碍(如果它们不先饿死自己或崩溃的话)。

网络性能危机（另见hot[即时评论]）也是类似的情况：非常浪费，并且还没（尚未？......）有自我限制。在过去，我不得不说，即使性能有限，安全性也是可以承受的。通过减少明显的膨胀和启用不太明显的优化，可以同时获得性能和安全性，而且现在是可能的。当时的根本原因和现在一样：太多的开发人员没有使用和他们的用户群一样的客户端系统，他们不知道他们所产生的网络、内存和CPU成本。以前，这些成本很难看到。而现在情况大不相同了：每个浏览器都有一个非常好的 Dev Tools 控制台，没有理由不去使用它。

我对像 NPM，CPAN，go get 等这样的依赖包管理系统感到厌恶，它们可能比手动依赖管理更危险，尽管这种做法存在巨大风险，正是因为它们使您的项目依赖图的发展变得更加“容易” - 从而隐式地增加了您信任的个人和组织的数量。 （并且他们的可信度可能会突然变得更糟。）当语言的标准库存在重大差距时，第三方开发人员将急切地用新的依赖关系来填补这些空白，从而以便（并不总是有意识地）继承下去。我强烈支持 那些正在努力填补 JavaScript 标准库中的空白 的人的做法。

社交媒体继续放大人们的最坏情绪，而社交媒体公司的一些高管仍然是问题的一部分。处理社交媒体的毒性和滥用仍旧是一项长期的，需要多方面的努力， 但作为工程师、项目经理、设计师和管理者，我们可以立即做的一件事是将“参与”作为“成功”的主要或唯一衡量标准。它具有游戏性和游戏性[保留一个游戏性就好]，并且无法在社交媒体上远程捕捉真人的真实体验。人们的经历往往 非常糟糕，我们作为软件开发人员负责处理我们构建的一切后果。我们是在鼓励人们学习和成长，还是在放大纳粹（Nazis）和契卡（前苏联秘密警察组织 -- Chektists）的蠢货？坚持简单化的言论自由 并不会让我们避免回答这个问题。

不幸的是，我想解决所有这些问题。我在 2018 年度过了一段非常有趣的时间，从事底层的防守（只是众多冒险中的一次），而且还有很多工作要做。 （迫切需要减少许多环境特权！）在帮助获取需要的HTTPS时，我还发挥了很小的作用，而这是值得的 。

但是，我发现最令人头疼的问题 - 一般的滥用类别 - 并不属于我最专业的领域。我的注意基本在语言问题上：有意义的界面，符合人体工程学和安全的库，内存安全性和类型安全性。但这种滥用让我感到心痛。

尽管如此，我看到人们确实提供了 20 或 10 或 5 年前似乎不可能实现的软件改进，我们真的在取得进步。这是我想在2019年看到的内容：

聪明人已经开始在所有的这些事情上努力工作了！我们可以让行业更接近需求，更好地为人们服务。未来更加严峻，还有很多工作要做...

原文链接：https://noncombatant.org/2019/01/06/state-of-security-2019/

翻译：看雪翻译小组 fyb波

校对：看雪翻译小组 一壶葱茜

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)