How exactly a debugged process can compromise the debugging process (machine)?

Question

Whenever one wants to attach to a process from Visual Studio, one receives this nasty message:

This question and its answers show the struggle to get rid of it. This Microsoft article tells us about the potential dangers of attaching for the debugging process/machine:

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.

Question: how does the debugged process is able to exploit the debugging process? (I am interested in just a few highlights, as I imagine that one can write a book about it).

And also, what is the purpose of having this warning when debugging on local machine's w3wp.exe process (I imagine that the vast majority of debugging sessions happen within the development machine). If local machine's w3wp process is compromised, you are in deep trouble anyway.

Answer 1

When you func eval something in the debuggee, you are effectively running code on the debugger. This is where the potential security problem could be.

For example, suppose the debuggee has some types that will load a natvis into the debugger. And suppose that the C++ Expression Evaluator has a security hole in it, that allows a buffer overrun attack through a natvis. Just by debugging a certain process, the remote process could take control of your local machine. Granted this isn’t likely, but the debugger isn’t hardened against this sort of attack. The nature of debugging means you have to let any code run.

In the other direction, once a process is being debugged, the debugger have the same permissions as it does. You can do anything you want.

This warning below pops up when attaching to an unknown users’ process. See this article: https://msdn.microsoft.com/ro-ro/library/ms241736.aspx

Answer 2

You get this warning when you attach to a process that runs with a limited user account. Like w3wp.exe, a web server is typically configured with such account so that an attacker cannot do too much damage after he figured out how to compromise the web server. Note how you normally use an account with admin privileges to debug the web server.

This opens up a generic security hole that is very similar to the one exploited by a "shatter attack". A privilege escalation, the unprivileged process exploiting the privileges of another process. The conduit is the debugger transport, the channel that lets a debugger control the debuggee. I think a socket in the case where the process runs on another machine, a named pipe if it runs on the same machine. The compromised process could fake the messages that the debugger interprets as normal responses. Anything is possible, nothing is simple, none of this is documented. Intentionally.

Note how you still use the remote debugger when w3wp.exe runs locally. It is normally a 64-bit process and VS is 32-bit, the remote debugger (msvsmon.exe) is required to bridge the bitness difference.

It is the kind of attack scenario where Microsoft has to throw up their hands and can no longer guarantee that such an attack cannot succeed and do real damage to your machine. The attack surface is too large. So they display the dialog, you have to interpret it as a "we are no longer liable for what happens next". Plausible deniability when it ever comes to a lawsuit. The info it displays is not actually useful to judge whether the process is compromised, but it is all they got. Life is too short to worry about it every single time you click Attach, lawyers never once made a programmer's job easier :)