How attaching to a process with a debugger can compromise system's security?

Question

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

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?

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: https://msdn.microsoft.com/en-us/library/ms242231.aspx — Artem Bychkov, Jun 21 '16 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 '16 at 13:44

score 3 · Answer 1 · answered Jun 21 '16 at 11:00

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.

answered Jun 21 '16 at 11:00

schroeder

123,438
55
284
319

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 '16 at 11:26
Yes, it is the debugger that requires more permissions (I said that) – schroeder Jun 21 '16 at 11:27
So, the process being debugged won't be granted more permissions, what's the risk then? – enkryptor Jun 21 '16 at 11:28
It will have access to more permissions. Especially if the malicious process is designed to exploit those permissions. – schroeder Jun 21 '16 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 '16 at 11:46
@enkryptor The debugger will be able to do anything the target process has permission to do. For example, if you debug a process running as administrator on Windows, you can evaluate an expression which will be run with that user's privileges. – billc.cn Jun 21 '16 at 12:20
@billc.cn so the risk is - my debugger might have the same privileges that malicious debugee process already has? – enkryptor Jun 21 '16 at 13:47
@enkryptor Sorry. I actually misunderstood the MSDN quote, which is a different issue from the one I was talking about. I think user2320464's answer is on point. – billc.cn Jun 22 '16 at 09:16

score 2 · Accepted Answer · edited Jun 16 '20 at 09:49

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.

How attaching to a process with a debugger can compromise system's security?

2 Answers2