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.
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 :)
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
Related
I've been trying to find the difference between these 2 types of debugging, but couldn't find it anywhere (been googling almost 30 minutes), so I'm asking here: What's the difference between live vs. offline debugging? What do people mean when they say a debugger is "live" vs. "offline"?
Debugging types
There are several ways of debugging that can be distinguished:
live debugging vs. post mortem debugging (what you call "offline" debugging, also called "dump debugging")
kernel debugging vs. user mode debugging
local debugging vs. remote debugging
which give 8 combinations in total.
For live debugging, you can distinguish between invasive debugging vs. noninvasive debugging.
Live debugging vs. offline debugging
In live debugging, the program is running and the debugger is attached to it. This means you can still interact with the program. You can set breakpoints, handle exceptions that would normally cause the program to terminate, modify the memory etc.
The downside of live debugging is its temporal/fluent nature. If you enter a wrong command or step too far, the situation is gone and might not be repeatable.
I mentioned that there are 2 sub-modes for live debugging: invasive and noninvasive debugging: in noninvasive debugging, the debugger does not attach to the target application. It suspends all of the program's threads and has access to the memory, registers, and other such information. However, the debugger cannot control the target.
In post mortem debugging, someone has captured a memory dump of a running program at a certain point in time. In many cases this is done upon a specific event, e.g. an unhandled exception that causes the program to terminate. Since the memory dump is a file on disk, you can analyze it as often as you want and you get the exact same situation.
The downside if post mortem debugging is, of course, that the program is not running, you can't interact with it and it's very hard to find out what happens next.
"Online" debugging is the normal process:
Tell the debugger to tell the program to step forwards;
Look at what the program state is at the moment;
Set a breakpoint for the future;
Tell the debugger to simply run the program;
If the breakpoint 'fires', have a look at the program state now.
There are two ways to "offline" debug:
You can take your source code and manually step through what the processor ought to be doing, watching for unexpected program paths.
Note if you do this, you need to diligently not "know" what the processor is "supposed" to do and just do that: you need to honestly obey the code as though you were the computer. Often you get other people, who don't know the code, to do this instead of you.
You take the result of a run-log, usually captured by a hardware probe, and use the debugger to "post mortem" the run.
The latter usually requires a processor that will transmit what it is doing out a "Trace" port (not all have this), and a hardware device (like a probe) connected to the Trace port to capture the data. That probe then communicates with a debugger, which takes the data and presents it to the programmer. The programmer can work backwards and forwards through this Trace log, and see the execution path that the code actually took, rather than the code the programmer thought it should take.
Some processors not only transmit what instruction they're currently processing, but also what data they read or wrote while doing this. A more sophisticated debugger can take this extra data and provide a 'snapshot' of the system at any time during the run, allowing the programmer to analyse why the code behaved the way it did.
The reason that it is called "offline" is because once the log has been captured, you can disconnect and power down the target, and look at the saved log at any time in the future without still being connected to the probe or processor.
From what I understand, on a high level, user mode debugging provides you with access to the private virtual address for a process. A debug session is limited to that process and it cannot overwrite or tamper w/ other process' virtual address space/data.
Kernel mode debug, I understand, provides access to other drivers and kernel processes that need full access to multiple resources, in addition to the original process address space.
From this, I get to thinking that kernel mode debugging seems more robust than user mode debugging. This raises the question for me: is there a time, when both options of debug mode are available, that it makes sense to choose user mode over a more robust kernel mode?
I'm still fairly new to the concept, so perhaps I am thinking of the two modes incorrectly. I'd appreciate any insight there, as well, to better understand anything I may be missing. I just seem to notice that a lot of people seem to try to avoid kernel debugging. I'm not entirely sure why, as it seems more robust.
The following is mainly from a Windows background, but I guess it should be fine for Linux too. The concepts are not so different.
Some inline answers first
From what I understand, on a high level, user mode debugging provides you with access to the private virtual address for a process.
Correct.
A debug session is limited to that process
No. You can attach to several processes at the same time, e.g. with WinDbg's .tlist/.attach command.
and it cannot overwrite or tamper w/ other process' virtual address space/data.
No. You can modify the memory, e.g. with WinDbg's ed command.
Kernel mode debug, I understand, provides access to other drivers and kernel processes that need full access to multiple resources,
Correct.
in addition to the original process address space.
As far as I know, you have access to physical RAM only. Some of the virtual address space may be swapped, so not the full address space is available.
From this, I get to thinking that kernel mode debugging seems more robust than user mode debugging.
I think the opposite. If you write incorrect values somewhere in kernel mode, the PC crashes with a blue screen. If you do that in user mode, it's only the application that crashes.
This raises the question for me: is there a time, when both options of debug mode are available, that it makes sense to choose user mode over a more robust kernel mode?
If you debug an application only and no drivers are involved, I prefer user mode debugging.
IMHO, kernel mode debugging is not more robust, it's more fragile - you can really break everything at the lowest level. User mode debugging provides the typical protection against crashes of the OS.
I just seem to notice that a lot of people seem to try to avoid kernel debugging
I observe the same. And usually it's not so difficult once they try it. In my debugging workshops, I explain processes and threads from kernel point of view and do it live in the kernel. And once people try kernel debugging, it's not such a mystery any more.
I'm not entirely sure why, as it seems more robust.
Well, you really can blow up everything in kernel mode.
User mode debugging
User mode debugging is the default that any IDE will do. The integration is usually good, in some IDEs it feels quite native.
During user mode debugging, things are easy. If you access memory that is paged out to disk, the OS is still running and will simply page it in, so you can read and write it.
You have access to everything that you know from application development. There are threads and you can suspend or resume them. The knowledge you have from application development will be sufficient to operate the debugger.
You can set breakpoints and inspect variables (as long as you have correct symbols).
Some kinds of debugging is only available in user mode. E.g. the SOS extension for WinDbg to debug .NET application only works in user mode.
Kernel debugging
Kernel debugging is quite complex. Typically, you can't simply do local kernel debugging - if you stop somewhere in the kernel, how do you control the debugger? The system will just freeze. So, for kernel debugging, you need 2 PCs (or virtual PCs).
During kernel mode debugging, things are complex. While you are just inside an application, a millisecond later, some interrupt occurs and does something completely different. You don't only have threads, you also need to deal with call stacks that are outside your application, you'll see CPU register content, instruction pointers etc. That's all stuff a "normal" app developer does not want to care about.
You don't only have access to everything that you implemented. You also have access to everything that Microsoft, Intel, NVidia and lots of other companies developed.
You cannot simply access all memory, because some memory that is paged out to the swap file will first generate a page fault, then involve some disk driver to fetch the data, potentially page out some other data, etc.
There is so much giong on in kernel mode and in order to not break it, you need to have really professional comprehension of all those topics.
Conclusion
Most developers just want to care about their source code. So if they are writing programs (aka. applications, scripts, tools, games), they just want user mode debugging. If "their code" is driver code, of course they want kernel debugging.
And of course Security Specialists and Crackers want kernel mode debugging because they want privileges.
Is there any bottleneck above the physical the cpu and HAL? Or are there multiple ways a process could start under Windows XP, Vista, or 7, that don't invovle CreateProcess at some point?
Given the comment on your question:
Building an Anti-Executable driver, just planning, wondering if controlling createprocess would be enough.
No it wouldn't be enough if security is your concern. There is NtCreateProcess below that one for example. And those aren't the only ones.
The best way provided by the system is a file system filter driver. In fact the WDK comes with samples that require only a moderate amount of change to do what you're asking. Since you asked about XP you can use a minifilter if you can get away with support for XP SP1 and later.
PsSetLoadImageNotifyRoutine and PsSetCreateProcessNotifyRoutine are unfortunately only notifications. So they don't allow to do anything about the event that they notify about. And you really shouldn't attempt to work around this.
In the old times I have seen some clever implementations using SSDT hooks on ZwCreateSection that would exchange the returned handle with one to an executable that shows an error message. Since the executable itself sees the original command line, it can then show a nice error message informing the user that the command has been banned for reasons xyz. However, with Vista and later and even on XP and 2003 64bit (x64), it's going to be harder to write the SSDT hooks. Not to mention that everyone would frown upon it, that it requires quite extensive experience to get it right (and even then it often has flaws that can cause havoc) and that you can forget any certifications you may be aspiring for in the Windows Logo process.
Conclusion: use a file system filter driver to deny access to unwanted executables. With a minifilter the learning curve will be moderate, with a legacy filter I'll recommend you take a few courses first and then start your first attempts.
Looking through a quick disassembly of CreateProcess, it appears that the two main things it does are:
Call NtCreateUserProcess (this is syscall 0xAA) to actually create the process structures in the kernel (PEB, etc.)
Start the new process with a call to NtResumeThread (syscall 0x4F).
The Windows Internals books certainly detail this process very well.
I'm not sure if there are designated hooks in the kernel which would allow you to create your anti-executable driver. It used to be that you could hook the "System Service Dispatch Table" to change how these system calls behaved. But now, technologies like PatchGuard prevent a driver from doing this (and allowing the system to run).
I am writing some testing software that receives some source code, compiles it on the server, executes it, forward input from the database, catches output and compares it with one in the database to see if it is correct. The problem is that source code can be anything (it is written in c/c++ and compiled with visual studio cl), so I need to prevent somehow malicious users. I am automatically killing those processes if they run longer than some time, or use more memory than allowed.
The question is, can I only allow those processes only to write and read from standard in/out streams and to deny any other access rights on windows.
Please excuse my English.
Thank you in advance.
Probably Job Objects can help you (see http://msdn.microsoft.com/en-us/library/ms684161(VS.85).aspx). This very powerful feature is not good known.
Working with jobs is very easy. You can create a job with respect of CreateJobObject and set a lot of different restrictions like time, memory and some restrictions. Then You can create a process with suspended flag, assign process to the job and resume the process. Then you receive full control under the created process and all tree of child processes, which the process can create. Job feature exist since Windows 2000.
Another modern way is User Interface Privilege Isolation (UIPI) (see http://msdn.microsoft.com/en-us/library/bb625963.aspx) or the way of usage Low Integrity Processes introduced by Vista. See http://msdn.microsoft.com/en-us/library/Bb250462#dse_stlip how to create a process with Low Integrity.
I need to monitor and, if it is needed, decline process start in the Windows XP and Vista OS?
What are known/documented/undocmented methods? What about known hacks of this methods?
(It will be used for the shareware firewall/security software).
Be very careful with any code that thinks it knows enough about what a user is doing to know whether or not to allow a process to start. It's a great way to find out how much you don't know about your users, but only if you provide an email address for the users to send complaints to.
An example was some VPN software I worked with that hooked into the Windows system to be notified whenever a DLL was loaded. It actually caused BSOD when running a very common application - Visual Studio. The manufacturer wasn't aware of how modular VS is, and that starting it loads many DLLs, and sometimes even more during execution, as new features are loaded.
When you put yourself in the position to do things for your users, you have the responsibility to know enough to do them correctly.
For monitoring you can use WMI events.
There is no[1] method to decide whether to allow the start or not. If you are on Pro/Biz/Ent/Ultimate editions group policy can be used to block specified executables from being launched, or limit to a specified list.
[1] As far as I am aware.