在 20 世纪 90 年代中期至后期，最有趣、最有成就和最有成效的黑客组织之一是 L0pht Heavy Industries，这是一个由“灰帽”（即，主要是善意的）黑客组成的松散联盟。 在那些年里，L0pht 因发现和公开许多软件漏洞，尤其是在 Windows 中，而赢得了全球恶名，并激怒了微软。 加上他们的密码审计工具 L0phtCrack 的成功（除了暴露选择不当的密码外，还证明了早期 Windows NT 身份验证实现中固有的弱点），L0pht 对糟糕的安全编程的持续曝光在微软缓慢但明显的改进以解决其产品中的安全缺陷方面发挥了重要作用。

L0pht 的名气和声望在 1998 年达到顶峰，当时他们的八名核心成员被邀请在美国参议院就互联网安全提供专家证词。 其中一位成员是克里斯·维索帕尔，又名 Weld Pond，一位资深的计算机安全工程师、研究员和程序员。 克里斯与他许多前 L0pht 同事一起，现在在咨询公司 @stake 工作，L0pht Heavy Industries 于 2000 年 1 月与该公司合并。

克里斯在百忙之中抽出时间，以 @stake 研发主管的身份接受了 Paranoid Penguin 的审问。 他的回答忠实于 L0pht 的旧风格，坦诚、信息丰富且周到。

米克 我们的许多读者都熟悉您在 L0pht 的工作，但您最近在公众视野中出现得较少。 您能描述一下您目前在 @stake 的工作以及它与您以前的工作有何不同吗？

克里斯 我是 @stake 的研发主管。 从管理角度来看，我负责监督顾问和开发人员正在进行的不同研究和工具项目。 研究领域包括取证、攻击模拟、无线和应用程序。 就我个人而言，我最关注的是应用程序安全领域。

实际上，这与 L0pht 有相似之处。 每个人都有自己的专业领域，并且有机会从事他们感兴趣的技术，无论是工具开发还是漏洞研究。 @stake 的不同之处在于我们构建的所有研究和工具都具有业务需求。 大多数都源于我们在与客户合作时看到的问题，或者源于自动化我们作为咨询实践的一部分手动执行的安全测试的需求。

米克 您最近使用过哪些技术？

克里斯 最近，我一直在研究应用程序安全问题。 如何从一开始就安全地设计产品？ 如何使用安全编码技术来实现它们？ 如何测试它们是否安全？ 这是一个难以解决的问题，因为您必须将其融入现实世界中构建软件的方式：预算有限且时间压力极大。

我们提出的解决方案是将安全性构建到开发过程的不同阶段。 我们已经提出了一些技术，用于在设计过程中绘制应用程序的威胁路径。 这使我们能够有效地发现设计缺陷，同时确保我们对整个设计进行了某种程度的覆盖。 下一步是构建工具来做到这一点。

对于实现过程，我们构建了一些工具，通过分析源代码甚至二进制文件来模拟应用程序的行为。 这是语义分析，而不是我们之前使用 SLINT [L0pht 开发的代码审计工具] 所做的简单词法分析。 它允许自动检测会导致缓冲区溢出或脚本注入等问题的错误代码。 来自 L0pht 的 Dildog 和 Tim Newsham 应该为这个杰出的工具获得赞誉。

为了实现自动化安全测试，我们正在开发应用程序渗透测试工具，这些工具可以模糊测试（发送随机问题数据）任意应用程序协议，例如 HTTP。 我们可以在实验室环境中设置一个应用程序并启动自动化攻击。 这些工具非常适合查找缓冲区溢出、格式字符串、规范化和脚本注入问题。 其他工具是垫片和代理，用于在应用程序通过线路、系统调用或 RPC 调用读取和写入数据时对其进行操作。 我希望这些类型的工具能够成为人们在发布软件之前遵循的标准质量保证流程的一部分。

米克 的确如此。 说到软件，您现在还有很多时间编码吗？ 有什么正在进行的工作您愿意讨论吗？

克里斯 我最近没有找到时间进行任何实质性的编码工作。 大部分时间我都在创建概念验证代码或脚本来尝试特定的应用程序攻击。 如果我必须提到一件值得关注的酷事，那绝对是我们的源代码和二进制语义安全分析工具。 这将为在软件发布之前（和之后）检测安全问题的能力带来一场革命。

米克 您是否看到整个软件行业在将安全性作为编程项目的设计目标，而不是事后才考虑方面有所改进？

克里斯 是的，当然。 我们一直在研究的安全软件开发技术和工具受到了我们软件客户的好评。 这在很大程度上是由于过去几年（很多年？）因不安全产品而受到抨击。 经验丰富的技术客户根本不再接受它。 它正在成为购买决策的一部分。

事情正在改变的另一个原因是公司正在认识到，事后修补漏洞非常昂贵，更不用说公关噩梦了。 他们终于意识到，有人实际上在下载试用版，在他们的实验室中破解它们并发布他们发现的内容。 [软件公司] 无法再隐藏他们糟糕的安全状况了。 此外，预先构建安全性更便宜。 我们使用 45 个客户参与的数据中的漏洞和修复它们的成本构建了一个“安全投资回报”模型。 数据表明，与在交付后尝试附加安全性相比，从一开始就构建安全应用程序可以节省 21% 的成本。

米克 在过去的几个月中，开源世界也经历了安全危机，Secure Shell、Squid、SNMP 和 zlib 等都出现了一系列漏洞。 然而，其中一些受影响的软件包，特别是 OpenSSH，是由 OSS 社区中最优秀、最聪明的人维护的。 这种趋势仅仅是运气不好吗？ 软件是否变得无法安全地复杂化，还是您看到其他解释？

克里斯 是的，其中一些非常复杂。 SSH 在升级到 2.0 版本时，复杂性有了很大的飞跃。 我认为已经进行的代码审计消除了重要应用程序中的许多唾手可得的漏洞。 闭源供应商正在这里迎头赶上。 但我不认为这消除了几乎所有问题。

需要付出更多努力，而不仅仅是代码审计。 需要对设计进行威胁建模和应用程序渗透测试，例如模糊测试。 某些问题，例如困扰 SNMP 的 ASN.1 问题，很难通过审计找到。 数据路径正变得非常复杂。 我还认为漏洞研究人员正在变得更好，并且有更多人参与其中。

米克 您的 @stake 同事 Dr. Mudge 最近一直在谈论风险管理以及其他不那么技术性的 IS 安全方法。 您认为公司和组织在以这种方式揭秘 IS 安全性以及将良好的安全策略和实践制度化方面取得了哪些进展？

克里斯 公司中的业务经理需要了解没有足够安全的风险。 这种理解不应仅限于 IS 部门。 一旦为负责损益的人员量化了安全事件成本，他们就会开始看到安全性的价值并愿意为此付费。 然后，经营业务的人将有更大的预算来分配给安全产品和服务。 一旦公司的管理人员了解了风险，就更有可能在全公司范围内采用安全实践和政策。

米克 有哪些方法似乎可以有效地促使组织采用更好的安全策略和实践，尤其是在向非技术经理推销这些概念时？

克里斯 演示效果很好。 告诉一位非技术经理，他的上游互联网连接可能被嗅探，并且他的公司正在明文发送敏感信息是一回事。 向他展示财务部门刚刚通过电子邮件发送给外包工资单公司的最新工资更新是另一回事。 当您获得数据时，它会触动人心。 非技术人员在理解漏洞可能造成的后果方面存在问题。 这太假设了。

米克 这当然也是我的经验。 顺便说一句，我想起您的 @stake 同事 Frank Heidt 将在今年 10 月的 Linux Lunacy Cruise 上进行完全相同的演示（并不是我在推销这个由Linux Journal赞助的精彩活动）。 这是一个对我们的读者至关重要的问题：您自己使用 Linux 的经验是什么？

克里斯 呵呵，我是个老手了。 我在 1994 年在 L0pht 设置了我们的第一台 Linux 机器。 我记得是运行在 486 上的 0.99.pl14 内核。 我将其配置为我们的互联网网关，通过 28.8 路由我们的 C 类网络。 我当时运行的是 NCSA Web 服务器和 sendmail。 要想重温一下旧时光，请查看 L0pht 网站在该机器上的运行情况：web.archive.org/web/19961109005607/http://l0pht.com。

我们使用 DESLogin 是因为那时是 SSH 出现之前的时代。 Linux 是我第一次接触 UNIX 编程。 我可以使用 SunOS 2.4 系统，但它没有 Linux 拥有的开发工具。 Linux 过去是，现在也是一个出色的学习环境。

米克 从安全角度来看，您认为 Linux 的优势和劣势是什么？

克里斯 与许多其他操作系统相比，Linux 具有更简单的安全模型和配置，尽管随着时间的推移，事情变得越来越复杂。 如果您没有做任何太复杂的事情，这种简单性是一个很大的优势。 其他系统的大部分复杂性最终都会让程序员和管理员束手无策。 更少的需要以 root 身份运行的东西，几乎可以不以 SUID root 身份运行任何东西的能力，以及文本配置文件，使得锁定系统变得容易。 Linux 一直非常没有病毒，即使在执行日常危险任务（如阅读邮件和浏览）时也是如此。 这证明了基本良好的安全设计。

另一方面，对于 Linux，每个人都是程序员，并且让我们面对现实，并非每个人都了解安全编码。 当我安装以某种方式暴露于互联网的软件包时，我并不总是想进行代码审计。 甚至有些软件包的作者明确声明该程序是不安全的，并且不要费心联系他或她。 这是不可接受的。 Linux 安全性的优势可能会被一个编码不良的应用程序所抵消。 但当然，闭源系统也是如此。