在生产环境中部署调试符号(pdb 文件)的风险是什么？

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

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

编辑: 后续问题/澄清

所以基于目前为止大家的回答，这个问题似乎可以简化一点。NET 应用程式。迈克尔 · 马多克斯的回答中 John Robbins 的博客连接的这一段突然出现在我眼前:

一个.NET PDB 只包含两个 信息、源文件名和 它们的行和局部变量 所有其他信息都是 已经存在于.NET 元数据中，因此 没有必要重复相同的 在 PDB 文件中的信息。

对我来说，这重申了其他人一直在谈论的反射器，其含义是，真正的问题是访问程序集。一旦确定了这一点，关于 PDB 的唯一决定就是您是否关心公开文件名、行号和本地变量名(假设您从一开始就没有向最终用户显示堆栈跟踪)。还是我把这个问题过于简单化了？

27745 次浏览
小开

Somebody can "restore" the complete source code of your application. If it is Open Source you do not need to worry. If it has some IP (algorithms, protection, licenses), it is probably not a good idea.

It is true that tools like Reflector can reconstruct parts of your code even without PDB files, but obfuscations can help (well, just a little bit).

小开

If you're deploying to a production environement in your own organization, then it's not a security problem.

If you're selling your software to other entities, then .pdb file can give someone interested in reverse engineering a leg up - that may or may not be a problem for you.

However (to be clear), you don't want your stack traces being displayed to the client - whether or not the .pdbs are available. But if you're just logging the traces and presenting a 'pretty' error page to the client, it's not an issue.

小开

By having debugging symbols, an attacker can determine global variables, function offsets, etc., of interest.

So he could see your system has a function like:

AddAdminUser(string name, string password);

And know its offset. If your program is compromised, he could call this function to give himself admin privileges.

Or something like:

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

And knows what bit to flip to switch your application into an insecure mode.

Alternatively, this would take quite a bit of reverse engineering time to figure out. Not an insurmountable amount of time, however.

But . . . this all implies your attacker is already in a position where he can compromise your program. If that's the case, you already lost.

If you have a good business reason to deploy pdb symbols, go ahead. Deploying PDB's won't make you insecure. If you don't have a good reason to deploy, you shouldn't do this as it will make attacks slightly easier.

You can also create public PDB files - these strip certain pieces of information, but give you enough symbols to generate a stack trace and do basic debugging. Details are here. Microsoft deploys public PDB's on its symbol server for all to use.

EDIT: Most of what I said applies to the concerns around deploying PDB's for native code - I think a lot of these concerns people carry over to .NET as well, even though assembly metadata conveys quite a bit of this already.

小开
最佳答案

Here is another question to look at:

Are there any security issues leaving the PDB debug files on the live servers?

And more info on PDB files:

PDB Files: What Every Developer Must Know

In general, I always include pdb files in my deployments, the gains are too huge to ignore.

If you never expose a stack trace to your users (and generally you shouldn't), there isn't really any additional security risk of deploying PDB files.

When a user visible stack trace happens, the user can see the full stack trace including your file name and file line numbers. This could give them some idea of how your app is architected which would potentially help them if hacking.

A bigger security threat is something like Reflector which when used on your DLLs will allow them to view your source code, with or without pdb files.


提交答案