What's the risk of deploying debug symbols (pdb file) in a production environment?

Question

I have an application that logs exception strack traces and I wanted those stack traces to include file names and line numbers when deployed in production. I figured out how to deploy the debug symbols w/ the assembly, but in the process of researching the issue I ran accross this question, which implies that it's not a good idea to include pdb files in a production environment. A comment to the accepted answer says "...debugging information can give away sensitive data and be an attack vector. Depending on what your app is."

So what sort of sensitive data might be exposed? How can debug symbols be used to compromise an application? I'm curious about the technical details, but what I'm really looking for is a practical way to evaluate the risk of including debug symbols for any given application and production environment. Or to put it another way: what's the worst that could happen?

EDIT: follow-up question/clarification

So based on everyone's answers so far, it seems like this question can be simplified a bit for .NET applications. This bit from the John Robbins blog linked in Michael Maddox's answer kind of leaped out at me:

A .NET PDB only contains two pieces of information, the source file names and their lines and the local variable names. All the other information is already in the .NET metadata so there is no need to duplicate the same information in a PDB file.

To me, this reiterates what others have been saying about Reflector, with the implication being that the real issue is access to the assemblies. Once that's been determined, the only decision to make with respect to PDBs is whether or not you care about exposing file names, line numbers, and local variable names (assuming that you're not showing stack traces to end users to begin with). Or have I oversimplified this too much?

Whitebait

@Matt: Is this a Desktop application, web, compact or...? – Tooley

@Kb - in this particular case, it's a console app that we run with a scheduler. It was develpoped in-house for internal use, so anyone who can see the pdb file would also be able to see the source code, so I'm not too worried about this particular app. I'm more interested in the general/practical case so I can decide whether or not to risk it with other apps, like, e.g. a desktop app installed on laptops that are occasionally connected to sensitive data on our network. – Whitebait

Answer 1

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.

Isagogics

Thanks for links. So it looks like at least part of the equation is where the application is deployed (i.e. desktop v. web server). – Whitebait

Answer 2

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.

Minna

I beleive Matt is talking about .Net. What extra information could one get from a PDB that not also is already available through a tool like Lutz' Reflector? – Lorenz

Source & line information immediately jumps to mind. I don't believe local variable names are present in the metadata. – Nigrosine

@Lars - I never said it would help :) I think this whole fear around PDB's and reverse engineering is very misplaced. The sort of person who can use PDB's to reverse engineer can use a decent disassembler that supports annotations. – Nigrosine

I can see how local variable names in very long methods might help reverse engineering, but source file names and line information? Not real a risk compared to tools like Reflector if you ask me :) – Lorenz

@Lars - I think that another way to express what Michael Maddox and I are saying is that giving the .pdbs to someone who has the assemblies often isn't really a security risk. Making a stack trace available to someone who doesn't have the assmeblies might be. – Minna

So, if I'm understanding this, it's worse (more risky) to display a stack trace in a web application than it is to include PDBs w/ a desktop application (because of access to assemblies). Is the larger lesson simply that you shouldn't include anything sensitive in source code? – Whitebait

Answer 3

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.

Nigrosine

I believe Matt is talking about .Net. You can already get all the source from a tool like Lutz' Reflector even without a PDB. – Lorenz

@Lars - Updated my comment to call out that most of this is native code. I think a lot of people just have an irrational fear that PDB's make reverse engineering possible, and believe that attackers don't know how to use disassemblers like IDA Pro. I believe these fears get incorrectly brought into managed code as well. – Nigrosine

Answer 4

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).

Guzman

I believe Matt is talking about .Net. You can already get all the source from a tool like Lutz Reflector even without a PDB. – Lorenz

Lars, I completely agree, Reflector is great tool for reverse engineering. But sometimes the result code is not very readable, especially if source was obfuscated. PDB files will make life even better. – Guzman