Two bugs/problems in 3.4.10

Hello.

I recently updated to PG 3.4.10 from 3.1.50. Because I was very *VERY* angry with Securom for putting their filthy little rootkit onto my machine when I installed a Myst demo (this new one can't even be removed properly with Regdelnull and, once on your system, completely bypasses even PG), I went ahead and did a total hard drive reformat and clean install. I figured that would have the added advantage of avoiding any problems with updating PG. For the most part, I was right. PG installed just fine and some of the new features really had me geeked out (for instance, the opportunity to ignore changes to some applications, like those that are updated often, is very convenient).

I *do* have two problems in 3.4.10, though, and I'm hoping Wayne, Gavin, and/or some knowledgeable users can help me. In order of severity, my persistent problems are:

(1) I am unable to deny svchost the power to modify protected applications. The box for allowing it to do that is checked and greyed out. Why? Is this permission now *necessary* under 3.4.10 In 3.1.50 this was not necessary and it worries me to be denied full control over this application, as (a) it is a huge part of how our boxes connect to the internet and (b) trojan writers love to make little programs that masquerade as instantiations of svchost. Can anything be done about this? I never gave svchost permission to modify apps under 3.1.50 and not once did I have a problem, so I don't imagine it's needed. Can anyone fill me in on why this is happening and how, if possible, I might remove this permission from svchost?

(2) This one is much less important to me, but it bears mentioning: rundll persistently fails to show up under my <Security> list. I have it set to <Permit Once> because this is another very common road of access for malware et al., but it is not appropriately listed under <Security>. For the first week after my reformat, on booting up PG persistently reported (something very roughly like) "unable to communicate with at least one program; set to 'permit once' as a default." Rundll would then show up under the <Security> tab as set to permit once (which was fine with me, anyway), but on each reboot the error message would occur. After about a week that went away and was replaced with my current situation (no error message, but no access for changing startup permissions under the <Security> tab). Has anyone else encountered this little oddity? If so, has anyone any suggestions for what to do about it? In my own case it's not that big of a deal because the <Permit Once> setting is exactly what I want, but it occurs to me that many other users might not want that. Besides, I take it to be a basic desideratum that the user have direct and unproblematic access to the execution permissions of all important programs, excepting those that would crash and/or lock up Windows if improperly tweaked by an inexpert user.

I tried fixing these problems by disconnecting from the internet and then running PG in Learning Mode again for a while, but to no avail.

Does anyone have any advice? Has anyone else encountered these problems?

Yours,

David

 

Have you tried removing svchost from the Protection tab? The thing is, trojans pretending to be svchost won't get the same permissions as the actual svchost since it checks the program's hash. If it were to be patched or replaced, ProcessGuard will pop up with an error message stating the program's hash has changed. Also, if you protect svchost from being modified, malware can't patch it's memory. The only other issue with svchost that I know of is that it can be used to download files from the internet without actually patching it or anything. Of course, the trojan has to be allowed to run for this to happen and it's actually a firewall's place to stop this rather than ProcessGuard's.

 

Is it rundll or rundll32? If it's rundll then I saw this: http://www.processlibrary.com/directory/files/rundll/

You shouldn't have rundll on an OS that can run PG.

 

Hi, StriderSkorpion.

No, I hadn't thought to try removing it from the list. Good call--I'll try it tonight and see what I get.

I know it's not a huge issue for svchost to have the permission to modify apps; I just don't like giving such permissions to programs that don't actually need them, especially if they're heavily involved in my box's network activity. Also, since I unwittingly allowed the (as-yet unexploited) Securom rootkit on my machine once before, this time around I want to do anything I can to prevent zero-day exploits. I mean, I don't do any risky downloads or anything, but all *sorts* of mainstream commerical software is cropping up with these unforgivable kits in them as ways to enforce the DRM mania. Shoot--mine came in a FREE DEMO of Myst V!! That is simply absurd. I figure it's only a matter of time before some clever and dedicated group of criminals manages to exploit the situation.

Anyway, I'll try your suggestion tonight.

Yours,

David

 

Hi, SpikeyB.

You're right, of course--it's rundll32, not rundll. I was being a bit sloppy and imprecise. Sorry about that.

Yours,

David

 

Hi, StriderSkorpion.

Ecch...no good. I did as you suggested, but I thought I'd try a little experiment and remove svchost from both the <Protection> tab *and* the <Security> tab to see if the <Security> tab was working properly. It is not working properly.

Svchost is no longer listed on the <Security> tab but still operates with the <Permit Always> setting I gave it before (much like rundll32...). For whatever reason , the <Security> list appears not to be updating itself as it should.

Anyway, I also removed svchost from the <Protection> list and then manually re-added it, but the <Authorize to Modify> button is still checked and greyed out. Oh, well--it was worth a shot...

Yours,

David

 

I figured as much since it's probably hardcoded into ProcessGuard. If you remove it from the Protection tab, it shouldn't be able to modify any processes. Of course, the downside would be that it wouldn't be afforded any of the protection. As I stated earlier, as long as it's protected from being modified, it shouldn't pose a siginificant risk.