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

Question

Are there any security issues keeping the .NET PDB files on the real server?

I know that throwing exceptions might take a bit longer , but who throws exceptions during normal execution anyway? :-)

But from a security perspective? any issues?

Cuspidate

Most people recommend to keep PDB's in production. Please reconsider the accepted answer. – Rexanne

Answer 1

I think a fair argument is also that not leaving the PDBs on the live servers is a risk. In the case where production is crashing and the problems can't be reproduced on dev or UAT, it's much more time consuming (and perhaps impossible) to diagnose where the error is occurring.

At the very least, the PDBs that match the deployed DLLs should be in a ZIP file on the production server somewhere. They should be easily located by people other than yourself in case you aren't around to assist.

Also see PDB Files: What Every Developer Must Know by John Robbins.

Yoheaveho

wintellect.com/pdb-files-what-every-developer-must-know Provided link does not work anymore – Dekko

Answer 2

If your system isn't secure with the PDBs, it's probably not secure without them. Obviously, it depends how valuable the better error reports are to you. Personally, I value that a lot, so tend to deploy the PDBs.

Bellinzona

Answer 3

The only problem you may encounter when publishing .PDB files to your website is when an exception occurs, and you forgot to set the CustomErrors property in web.config. The stack trace will be displayed with file names and line numbers, which may be a security problem.

I don't think there are any other risks.

Servetnick

Answer 4

If server is IIS, no. These files will not be exposed to the public if kept in the right places (website\bin). Occasionally I've found intermediate (obj directory) files on web servers - this appears to be a favorite way to accidentally publicize binaries. Any cases where your pdbs are visible, you dlls are also visible, which is worse.

As noted by activa, the stack trace is plenty useful to a hacker with or without line numbers. Keep it private.

I assume any other program you might be running on a real server - services, and so forth - isn't publicly accessible at all.

Picklock

Answer 5

If you present failing exceptions to the end-user (aka in Yellow Screen of Death), then it might pose a risk of attacker a getting better insight into your system.

One of the possible solutions - to have an exception handling policy that:

1. Logs all exceptions with the original stack trace, additional information and a unique exception ID (Guid).
2. Replaces fired exception with a wrapper that contains only exception ID (for reference and feedback) and sanitized message (i.e.: no connection strings) with discarded stack trace info.

Examples of Open Source Exception handling blocks in .NET:

• From Lokad

• From Microsoft

• Theory

Grunter

Answer 6

Basically PDBs are just below source code when it comes to poking about, and ASP.NET/IIS doesn't stop them from being downloaded either.

Now sure people would have to guess the assembly name, and that may be unlikely, but why take the risk?

Illustrational

As long as .PDB files are in the bin folder (where they almost always are), IIS will not allow you to download them. – Servetnick

Up to a point. However this relies on ASP.NET getting it right, and that no-one has changed the request filtering rules. Given that no software is bug free it's still a risk, after all, with .NET 1.0 you could bypass forms auth by changing a / to a \ – Illustrational

If ASP.NET doesn't "get it right", then the .pdb's are the least of your problems. Besides, there are only 3 things in a managed .pdb file: source file name, line numbers, and local variable names. Unmanaged (native) .pdb files are a different story... – Otila

Answer 7

Hmm - I'd lean on the side of security caution on this. I think you should have PDBs, but not on production servers. Besides, you should have Debug turned off on any live system. Debug is nasty, and you just don't want it when you don't need it.

From Scott Guthrie:

1. The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)
2. Code can execute slower (since some additional debug paths are enabled)
3. Much more memory is used within the application at runtime
4. Scripts and images downloaded from the WebResources.axd handler are not cached

Set deployment retail=true in your machine.config:

<configuration>
    <system.web>
          <deployment retail="true"/>
    </system.web>
</configuration>

This overrides debug, error and trace settings, which will prevent any error disclosure outside of the computer itself.

So now that you have debug turned off, no error or trace on, why would you deploy PDB's to the production server? Store them somewhere else, perhaps even your development server. Your code promotion script from Dev to Production can specifically exclude the PDBs, but archive them so that they're available if you ever need to do debugging of production.

Briquet

this does not answer the question asked. debug=true on production is different from putting pdb files on production. release build builds with 'pdb-only' flag do not affect performance (debug build builds with pdb-full flag and affect performance). Now whether it's a security issue? it seems that as long as you do not show the stack trace to user, it should be fine. see: #1307982 – Bowhead

Since this is a production system, and Retail="True" (you do have Retail="True", right???) the PDB's on the production system don't do anything for you. The security issue implications are: Don't deploy anything that's not needed. How do you know in that there isn't an undiscovered exploit in PDBs that you would circumvent by not deploying? If a file is not used by the production system, and having them there gains you nothing, then DON'T PUT THEM THERE. – Briquet

Debug != PDB. You can generate PDBs for release builds that don't have the slower debug code paths in them. You can also generate PDBs for precompiled ASP.NET sites. So why would you deploy PDBs to a production server? To output line numbers in your locally logged stack traces, of course! The switches you describe won't impact logging for libraries such as log4net. – Maidenhood