1

I’ve been trying to understand how operating systems protect processes from each other. My understanding of Windows security is that a process can call OpenProcess() (thereby allowing read and write access to the virtual memory of another process) as long as it has seDebugPrivilege and an integrity level at least as high as that of the other process.

It also looks as if a process can call OpenProcess() without seDebugPrivilege when targeting a process that belongs to the same user.

FYI: my testing to confirm this was done on a Win2008 R2 server. My method for testing whether a process could write to another process was using Meterpreter’s migrate function, which (among other things) makes an OpenProcess() call to a target process to create a Meterpreter thread inside of it.

My questions:

  1. Are the statements above correct, or have I screwed up my testing somewhere?

  2. What are the specific criteria that need to be met for an OpenProcess call to work? At the moment, it looks like it's:

    • has correct integrity level
    • has seDebugPrivilege OR has same SID as the other process

  3. If this is true, isn’t there a crazy amount of information an attacker can read or tamper from a computer they’ve compromised but don’t have root access to?

  4. What is the Unix equivalent of this? By default, can all of a user’s processes read and write to each other? Is this true for root too?
Ted
  • 11
  • 2
  • `SeDebugPrivilege` is just about the equivalent of root, which is why it's not granted to standard users by default. The security boundary in Windows is the user itself, so grabbing data from processes by the same user isn't breaking a boundary. – Steve Nov 19 '19 at 16:40

0 Answers0