I've been noticing several attempts by svchost.exe to modify memory owned by another program. I've been denying these and I've discovered no problems so far. I'm about to lock it down for good, but I wanted to ask for some opinions first. Is there any benefit to allowing svchost.exe to access memory from other programs? The only thing I can think of is it re-allocates unused memory to prevent poor memory management, but I haven't noticed any performance issues from denying...
I believe this could also be due to "sloppy code" - the approach I take here is to lock it down and then only allow it if there is an event that we can directly correlate with that action CSA is stopping.
What I am seeing is that svchost.exe runs so many child applications that it's almost impossible to create a manageable list of allowed child applications. My thought is that I'll probably end up having to allow svchost.exe to run all child applications to cut down on administrative overhead - is there any huge disadvantage to doing this?
I got the same response from one of our Microsoft experts here. Basically, svchost.exe is used by tons of other applications, so shutting it down is a risky move. I hadn't thought about allowing svchost.exe's child applications to run...the only disadvantage I could see is if an attacker used svchost.exe to deploy their payload, the rule would allow svchost.exe pretty much carte blanche. This seems like a trial and error approach type problem.
An update to this...I edited the rule yesterday and, looking over the logs, the rule is denying access to svchost.exe when I only grant access to child processes. That makes sense I guess, since it's svchost.exe DIRECTLY attempting to write the memory.
The only other solution I can think of that doesn't involve just opening up svchost.exe is trying the svchost.exe with flags (If you examine some of the Services that use svchost.exe, they use -k NETSVC or things like that). Also, I could rely on Microsoft security to keep C:\WINDOWS\system32\svchost.exe secure and just lock down any OTHER svchost.exe, because that would be a virus/spyware.
I agree - I've allowed svchost.exe to run any child applications, essentially extending complete trust to this file. Do you know exactly *how* a child process is run with svchost.exe? Really what I'm trying to discern is whether or not a virus or worm could theoretically launch itself with svchost.exe if the system is otherwise uncompromised.
And, yes, when I refer to svchost.exe above, I'm referring specifically to the application class CSA has defined for the version located within the C:\WINDOWS\system32 directory (so any malware with the same name in an alternate location would not be extended these rights).
I haven't gotten any experience yet, but I'm guessing a child process is where svchost.exe actually OPENS another process. That might be useful for creating rules to say only allow a certain action if it was opened by application x.
My thoughts are that Microsoft will update any security holes in svchost.exe when they come up and, before CSA, svchost.exe was allowed to write that memory, so it should be ok, as long as you make sure to specify C:\WINDOWS\system32\svchost.exe. It's not great, since you're losing some of the Day zero defenses, but it does a good job of locking down fake svchost.exe while allowing regular svchost.exe
Do you know exactly what svchost.exe is? For example, if a user opens up windows explorer and double-clicks a file, I'm assuming that file would be a child process of explorer.exe. Is it possible for a user to execute a file as a child process of svchost.exe? I would really like to understand what exactly svchost.exe is and what it's used for (so I can figure out how easy it would be to exploit a CSA rule that says svchost.exe can run any child processes it wants).
svchost.exe is kind've a "catch all" process for system services. If you look at Services in the Administrative Tools area of Control Panel, you can double click on many of the listed Services and notice under "Path to executable" that svchost.exe is the executable. Basically, several of these services use svchost.exe as the running executable to gather and send the information they need.
http://support.microsoft.com/?kbid=314056. There's also this Microsoft article, explaining what it does.