83

我有一个记录异常跟踪跟踪的应用程序，我希望这些堆栈跟踪在生产中部署时包含文件名和行号。我想出了如何使用程序集部署调试符号，但是在研究这个问题的过程中，我遇到了这个问题，这意味着在生产环境中包含 pdb 文件不是一个好主意。对已接受答案的评论说“......调试信息可能会泄露敏感数据并成为攻击媒介。取决于您的应用程序是什么。”

那么什么样的敏感数据可能会被暴露呢？如何使用调试符号来破坏应用程序？我对技术细节很好奇，但我真正想要的是一种实用的方法来评估在任何给定应用程序和生产环境中包含调试符号的风险。或者换一种说法：可能发生的最坏情况是什么？

编辑：后续问题/澄清

因此，根据到目前为止每个人的回答，对于 .NET 应用程序来说，这个问题似乎可以简化一点。迈克尔·马多克斯（Michael Maddox）的回答中链接的约翰·罗宾斯（ John Robbins）博客中的这一点让我大吃一惊：

.NET PDB 仅包含两条信息，源文件名及其行和局部变量名。所有其他信息都已在 .NET 元数据中，因此无需在 PDB 文件中复制相同的信息。

对我来说，这重申了其他人对 Reflector 的看法，暗示真正的问题是访问程序集。一旦确定了这一点，就 PDB 做出的唯一决定是您是否关心公开文件名、行号和局部变量名（假设您一开始没有向最终用户显示堆栈跟踪）。还是我过于简单化了？

4

4 回答 4

59

这是另一个要研究的问题：

将 PDB 调试文件留在实时服务器上是否存在任何安全问题？

有关 PDB 文件的更多信息：

PDB 文件：每个开发人员都必须知道的内容

一般来说，我总是在我的部署中包含 pdb 文件，收益太大而无法忽视。

如果您从不向您的用户公开堆栈跟踪（通常您不应该），那么部署 PDB 文件实际上并没有任何额外的安全风险。

当发生用户可见的堆栈跟踪时，用户可以看到完整的堆栈跟踪，包括您的文件名和文件行号。这可以让他们了解您的应用程序是如何构建的，这可能会在黑客攻击时帮助他们。

更大的安全威胁是反射器之类的东西，当在您的 DLL 上使用它时，它们将允许他们查看您的源代码，无论是否带有 pdb 文件。

于 2009-08-20T17:00:39.857 回答
15

如果您要部署到自己组织中的生产环境，那么这不是安全问题。

如果您将您的软件出售给其他实体，那么 .pdb 文件可以帮助对逆向工程感兴趣的人 - 这对您来说可能是也可能不是问题。

但是（要清楚），您不希望将堆栈跟踪显示给客户端 - 无论 .pdbs 是否可用。但是，如果您只是记录跟踪并向客户端显示“漂亮”的错误页面，那么这不是问题。

于 2009-08-20T16:56:14.623 回答
11

通过调试符号，攻击者可以确定感兴趣的全局变量、函数偏移量等。

所以他可以看到你的系统有这样的功能：

AddAdminUser(string name, string password);

并知道它的偏移量。如果你的程序被入侵，他可以调用这个函数来给自己管理员权限。

或类似的东西：

typedef enum {Basic, NTLM} AuthenticationMode;
AuthenticationMode g_authenticationMode;

并且知道要翻转哪些位以将您的应用程序切换到不安全模式。

或者，这将需要相当多的逆向工程时间才能弄清楚。然而，这不是一个不可逾越的时间。

但 。. . 这一切都意味着您的攻击者已经处于可以破坏您的程序的位置。如果是这样，你已经输了。

如果您有充分的商业理由部署 pdb 符号，请继续。部署 PDB 不会让您不安全。如果您没有充分的部署理由，则不应该这样做，因为这会使攻击稍微容易一些。

您还可以创建公共 PDB 文件 - 这些文件会去除某些信息，但会为您提供足够的符号来生成堆栈跟踪并进行基本调试。详情在这里。Microsoft 在其符号服务器上部署公共 PDB 以供所有人使用。

编辑：我所说的大部分内容都适用于为本地代码部署 PDB 的问题——我认为很多这些问题人们也会转移到 .NET 中，尽管程序集元数据已经传达了相当多的内容。

于 2009-08-20T16:59:05.977 回答
2

有人可以“恢复”您的应用程序的完整源代码。如果它是开源的，您无需担心。如果它有一些 IP（算法、保护、许可证），那可能不是一个好主意。

确实，即使没有 PDB 文件，Reflector 之类的工具也可以重建部分代码，但混淆可以提供帮助（嗯，只是一点点）。

于 2009-08-20T16:52:59.950 回答