4

Visual Studio shows a warning, trying to attach to a different user's process:

attach security warning

Searching for an explanation, I've found the MSDN article, claiming that:

An untrusted process that contains malicious code has the potential to damage the computer doing the debugging.

To my knowledge, it's quite the opposite - you actually can attach a process with a debugger in order to prevent its (presumably malicious) behavior. Assuming a malicious code is already running in my system, how attaching with a debugger to it can compromise the system's security even more?

2
  • 1
    There is another article at MSDN that vaguely says that, apart from debugger-specific exploits, there is a possibility of running untrusted code with the privileges of the debugger process. Maybe it is some VS debugger design issues, it is hard to infer from the article. Here is the link: msdn.microsoft.com/en-us/library/ms242231.aspx Jun 21, 2016 at 13:41
  • @ArtemBychkov that seems plausible - for instance, I can view an object's property with debugger, which might lead to execution of an unwanted code with elevated (debugger's) privileges
    – enkryptor
    Jun 21, 2016 at 13:44

2 Answers 2

2

If you scroll down the page of the provided msdn link under the See Also heading there's a link to Debugger Security which states:

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.

Debugger Security then provides best practices for various debugging scenarios.

To address your specific question how attaching with a debugger to it can compromise the system's security even more?, Debugger Security gives an example of:

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.exe, the Visual Studio Remote Debugging Monitor.

3

Your note that it's a "different user's process" is the key here. If the malicious process is limited to that user's context, then attaching a debugger (which usually requires deep permissions) gives the process access to more resources.

While a debugger might be used to prevent malicious activity, there is no way for the debugger to know what exactly you will do. You could simply run the process to completion to analyse the logs later.

The warning is appropriate, although there are possibly ways where it is not necessary. Better to have it in order to remind everyone of the very real problems.

8
  • I thought it's the debugger who needs special permissions, not the process being debugged.. What permissions the OS must grant to a process in order to allow its debugging?
    – enkryptor
    Jun 21, 2016 at 11:26
  • Yes, it is the debugger that requires more permissions (I said that)
    – schroeder
    Jun 21, 2016 at 11:27
  • So, the process being debugged won't be granted more permissions, what's the risk then?
    – enkryptor
    Jun 21, 2016 at 11:28
  • It will have access to more permissions. Especially if the malicious process is designed to exploit those permissions.
    – schroeder
    Jun 21, 2016 at 11:29
  • What permissions will it get? You said it's the debugger who must be granted permissions, not the debugee. Why should it have access to more permissions? (putting aside special debugger exploits for now)
    – enkryptor
    Jun 21, 2016 at 11:46

You must log in to answer this question.

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