Memory Protection

So by this reasoning, would it not follow that if someone allows csrss, lsass, svchost and ntvdm Physical Memory access (PG's default rules) then they don't want to be protected either? Since svchost can be called upon to do a whole host of tricks by other programs including malware, its inclusion is the most potentially troublesome in my view. While I would certainly agree that PG cannot (and should not) seek to overrule "bad" configuration decisions, the user should not be left completely in the dark should PG be disabled somehow - a periodic check on PG's hooks surely should not be too difficult to implement and can provide a further opportunity to alert users to possible malware on their systems.

Going OT a little, I suspect that DEP will offer far less than complete protection since it does require well-behaved programs that only mark the memory they need - one careless process marking too much would greatly weaken the protection DEP can offer. However it is an extra layer of defence that may help in some situations. Anandtech have a thoughtful article on this - A bit about the NX bit; Virus Protection Woes covering other problems with DEP.

 

Ok, I guess I'm one of those that you can consider slightly confused. I understand what you did write, but I'm left a little confused about what seems unsaid. As I understand it, a process has to have an Administrator security context to be able to read \\Device\PhysicalMemory, and an even more 'specialized' context to write to it. My question is this, if some piece of malware is running with a security context sufficient to read/write to \\Device\PhysicalMemory, wouldn't it also have sufficient privileges to install a kernel-mode driver that could accomplish the same thing anyway? I mean, all of this seems somewhat contradictory and self-defeating to me. You say PG protects \\Device\PhysicalMemory and that "there is NO way for malware to get around the protection"; yet, you also make the followup statement that "kernel mode code can do anything it wants, period". Isn't the real solution to make sure that you work 99.9% of the time in a non-Administrator account, and be extremely careful about any software that executes and installs while you are running with Admin privileges?

 

Hi,

that's because PG has also a "driver protection" option, which block any process to install such kernel driver, untill you allow it to.

regards,

gkweb.

 

As far as I am aware in regards to the physical memory access, you cannot "trick" svchost or any of those other executables into getting access to physical memory. If there is some "vulnerability" or "feature" in Windows which is found out to allow this ProcessGuard will block it in future builds.

In the meantime if you are paranoid and think svchost.exe is vulnerable to some unknown exploit then remove physical memory access from it, it shouldn't crash your computer.

 

Done. (who me? Paranoid? ). However is there a reason for having this permission set as a default for svchost?

 

Hi Paranoid2000, I have disabled svchosts.exe with Allow physical memory & services.exe with Install drivers/services all of today. Run everything I normally use, burnt a CD, updated SpySweeper to V3.2 which included a restart and have had no problems as yet.
I believe that disabling Install driveres/services for services.exe can cause problems for AOL users and probably some others.

Pilli

 

I always find it ironic that an ISP targetting new users has such a pig-awkward, resource-guzzling monster of an application that has to be run for access, which adds so many complications like with firewall configuration (especially for trying to get an "all ports stealthed" result with AOL's TopSpeed software running).

I've left drivers/services off with svchost/services for a while now (although, like yourself, I have noticed some applications need it to install and some to run). The physical memory issue though looks to be another matter since blocking the wrong processes would probably have a far more serious affect.

Peter2150,

Do you have access to a later (unreleased) PG beta with this services fix? (Edit: Never mind, just checked your sig...)

 

Very neat, I wonder if that is also applied to other system processes like SMSS.exe?
I do recall peter, that you had quite a session with Jason on those issues but did not recall the fix. So thanks for reminding me.

P2K - There have been many modifications in the private betas since the last Public Beta. I am sure Jason will list them for the final release.

Cheers. Pilli

 

please send me your articles.