7

When an exception occurs in a .NET application, the exception output also includes the path and file name of the code file that resided on the developer's machine. This shares some information that is useful in debugging, but also may present a security issue as shown in the following example:

D:\talks is private

In the above image the directory D:\talks comes from the developers machine and not the end user's.

Suppose I have a Visual Studio Solution file that has a PFX file with the password part of the name:

Example:  d:\my secret project\Obscure FOSS project\Signer-PW-Is-test123.pfx

Of course test123 isn't the real pfx password, but what if it was a more sensitive password that was used for other purposes (say domain admin).

Question:

Where is this string "Signer-PW-Is-test123.pfx" stored in the .NET DLL or exe?

Is it stored in the OBJ file?

How can I purge this data, or anonymize the information so that I don't leak what's unnecessary but still make it possible for engineers to debug the application.

Improve this question
4
  • Please explain what a "more secret" password is exactly?
    – Ramhound
    Jun 22, 2012 at 14:59
  • It should be in EXE and if you have any components done yourself it will be in that DLL.
    – Andrew Smith
    Jun 22, 2012 at 17:54
  • You could simply "eat" the exception messages. If you catch all exceptions and handle them silently the unhandled exception dialog is never shown. How is a path on a computer a security concern?
    – Ramhound
    Jun 22, 2012 at 19:49
  • 1
    It's not just .NET, Visual Studio has always compiled in paths used on the developer machine. I've used it when analysing malware to help determine who was responsible for writing it (or tie up two samples to the same source).
    – bobince
    Jun 23, 2012 at 10:19

2 Answers 2

Reset to default
2

I'm a little confused as to how you have this set up.

What makes you think that file path is stored in either assemblies at all? Are you using that PFX to sign the assemblies? If so, there's a pointer in the assembly attributes.

There is no way to obscure the filename at that level because the compiler needs to know the full path. You could possibly run it through obfuscation software, but that would still likely result in the string being present.

Another option is to make sure you compile in RELEASE so the debug bits aren't added. This will remove the pdb files and remove most of the entries to code file paths.

The only other option really is to compile the thing from a non-sensitive path, e.g.: d:\builds\1, and to remove all sensitive information from the file paths. Simply put: don't store the password in the filename.

Improve this answer
-1

You need to implement exception handling. For all system and API calls, check the documentation for a list of exceptions the method may throw. Then, properly account for those exceptions and you won't have problems such as these.

Improve this answer
1
  • 1
    Well, that doesn't quite solve the problem as the assembly itself will still contain pointers to file paths.
    – Steve
    Jun 23, 2012 at 0:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .