3 ms·

> This full system x86 emulator runs as SYSTEM, is unsandboxed, is enabled by default and remotely accessible to attackers. Can anyone more familiar with these

> This full system x86 emulator runs as SYSTEM, is unsandboxed, is enabled by default and remotely accessible to attackers. Can anyone more familiar with these issues tell me why Microsoft is still running this stuff as SYSTEM? Seeing as Tavis has been poking holes in the same component for a couple of months now, I assume it's a design choice and there has to be some good reason for it. Right?

dboreham 9y ago
Wondered that myself a couple of months ago when this first came up. I assumed: bacuase thoughtless, but perhaps there's an actual reason.
setq 9y ago
Windows is a rat's nest from hell when it comes to privilege separation. That was probably the only privilege level that allows it to communicate with what it needs to. Even worse, despite this patch, it's still sitting here running as local system on my box. Total fucking nightmare.
mnarayan01 9y ago
Are you asking about Defender itself or the emulation component? I'd think that Defender does need the higher privilege level for obvious reasons, though conceivably the more "risky" emulation could be done in a separate process with reduced privileges. It would be a pretty big undertaking though; just consider e.g. DoS on a multi-user system by attacking the process with dropped privileges. Not saying it's infeasible, but I think it would be complex.
- SomeStupidPoint 9y ago
  > by attacking the process with dropped privileges In what way is this not strictly better for the defender than if that same process was running as SYSTEM? I don't think limiting the capabilities of a child process (even by running it as "SYSTEM_LITE") impacts its scheduling priority, security settings, etc. It would depend on the policy around the process.
  - mnarayan01 9y ago
    > In what way is this not strictly better for the defender than if that same process was running as SYSTEM? You need to make sure there are no holes in the IPC. Like I said, it's presumably not infeasible, but it would have to be done right.
    - SomeStupidPoint 9y ago
      Why are there more likely to be holes in that IPC than the SYSTEM one? Why are those holes more dangerous than having the entire thing happen in SYSTEM land? Naturally, there's a danger that it's not bullet-proof and will lead to escalations/escapes. However, how is the risk of that not a strict improvement over the situation where it's running as SYSTEM and doesn't even need to bother with that? It sounds like it's strictly harder to weaponize faults in the component if they need to find a secondary problem in IPC encapsulation over just running code as SYSTEM as soon as they compromise the component.
- deleted 9y ago
  [deleted]
youdontknowtho 9y ago
For defender to be able to do the kinds of things that AV does it has to run as system. Once you are running as SYSTEM what does "sandboxing" even mean?

dboreham 9y ago

Wondered that myself a couple of months ago when this first came up. I assumed: bacuase thoughtless, but perhaps there's an actual reason.

setq 9y ago

Windows is a rat's nest from hell when it comes to privilege separation. That was probably the only privilege level that allows it to communicate with what it needs to. Even worse, despite this patch, it's still sitting here running as local system on my box. Total fucking nightmare.

mnarayan01 9y ago

Are you asking about Defender itself or the emulation component? I'd think that Defender does need the higher privilege level for obvious reasons, though conceivably the more "risky" emulation could be done in a separate process with reduced privileges. It would be a pretty big undertaking though; just consider e.g. DoS on a multi-user system by attacking the process with dropped privileges. Not saying it's infeasible, but I think it would be complex.

SomeStupidPoint 9y ago
> by attacking the process with dropped privileges In what way is this not strictly better for the defender than if that same process was running as SYSTEM? I don't think limiting the capabilities of a child process (even by running it as "SYSTEM_LITE") impacts its scheduling priority, security settings, etc. It would depend on the policy around the process.
- mnarayan01 9y ago
  > In what way is this not strictly better for the defender than if that same process was running as SYSTEM? You need to make sure there are no holes in the IPC. Like I said, it's presumably not infeasible, but it would have to be done right.
  - SomeStupidPoint 9y ago
    Why are there more likely to be holes in that IPC than the SYSTEM one? Why are those holes more dangerous than having the entire thing happen in SYSTEM land? Naturally, there's a danger that it's not bullet-proof and will lead to escalations/escapes. However, how is the risk of that not a strict improvement over the situation where it's running as SYSTEM and doesn't even need to bother with that? It sounds like it's strictly harder to weaponize faults in the component if they need to find a secondary problem in IPC encapsulation over just running code as SYSTEM as soon as they compromise the component.
deleted 9y ago
[deleted]

youdontknowtho 9y ago

For defender to be able to do the kinds of things that AV does it has to run as system. Once you are running as SYSTEM what does "sandboxing" even mean?