Aracılığıyla paylaş


Debugger Security

Applies to: yesVisual Studio noVisual Studio for Mac

Note

This article applies to Visual Studio 2017. If you're looking for the latest Visual Studio documentation, see Visual Studio documentation. We recommend upgrading to the latest version of Visual Studio. Download it here

The ability to debug another process gives you extremely broad powers that you would not otherwise have, especially when debugging remotely. A malicious debugger could inflict widespread damage on the machine being debugged.

However, many developers do not realize that the security threat can also flow in the opposite direction. It is possible for malicious code in the debuggee process to jeopardize the security of the debugging machine: there are a number of security exploits that must be guarded against.

Security Best Practices

There is an implicit trust relationship between the code you are debugging, and the debugger. If you are willing to debug something, you should also be willing to run it. The bottom line is that you must be able to trust what you are debugging. If you cannot trust it, then you should not debug it, or you should debug it from a machine that you can afford to jeopardize, and in an isolated environment.

In order to reduce the potential attack surface, debugging should be disabled on production machines. For the same reason, debugging should never be enabled indefinitely.

Managed Debugging Security

Here are some general recommendations that apply to all managed debugging.

Remote Debugging Security

Local debugging is generally safer than remote debugging. Remote debugging increases the total surface area that can be probed.

The Visual Studio Remote Debugging Monitor (msvsmon.exe) is used in remote debugging, and there are several security recommendations for configuring it. The preferred way to configure the authentication mode is Windows Authentication, because No Authentication mode is insecure.

Error dialog

When using Windows Authentication mode, be aware that granting an untrusted user permission to connect to msvsmon is dangerous, because the user is granted all your permissions on the computer hosting msvsmon.

Do not debug an unknown process on a remote machine: there are potential exploits that might affect the machine running the debugger, or that might compromise msvsmon. If you absolutely must debug an unknown process, try debugging locally, and use a firewall to keep any potential threats localized.

For information on configuring msvsmon, see Set up the remote debugger.

Web Services Debugging Security

It is safer to debug locally, but since you probably do not have Visual Studio installed on the web server, local debugging might not be practical. Generally, debugging Web services is done remotely, except during development, so the recommendations for remote debugging security also apply to Web services debugging. Here are some additional best practices. For more information, see Debugging XML Web Services.

  • Do not enable debugging on a Web server that has been compromised.

  • Make sure you know the Web server is secure before debugging it. If you are not sure it is secure, do not debug it.

  • Be especially careful if you are debugging a Web service that is exposed on the Internet.

External Components

Be aware of the trust status of external components that your program interacts with, especially if you did not write the code. Also be aware of components that Visual Studio or the debugger might use.

Symbols and Source Code

Two Visual Studio tools that require thinking about security are the following:

See also