I'm wondering if there is any hope that the impending final version of PG 3.0 will have technology in it to permit us to "Allow" certain drivers/services to be installed by Services.exe and not loose the protective power of PG by "having" to Allow Services.exe to global install drivers/services. I just don't see how many, many normal computer users can benefit from the full protection of PG without this ability. I mean there are 25+ million AOlers, 4+ million Norton Antivirus users, and lord knows how many other users with other specific programs that will not work as designed if Services.exe blocks drivers/services. Just a question and just my opinion.
I'll second siliconman01's motion, would be handy for we Norton users. (If its feasible, of course!!)
hopefully I'm not disclosing too much. This problem is being taken very seriously and there have been a number of approaches discussed at DCS. Of course, it will depend on whether the resp. implemention is feasible and working, whether it does what it's supposed to do and whether it's not damaging other parts of the protection/workings. So, there will still be some time this issue will be handled in the private betas and DCS beta team, but sooner or later, I'm rather sure you'll get a version that handles it. Unless there unexpectedly turns up something really really bad in the researching/coding/private betas... Andreas
Hi I was wondering if someone can help explain this issue to me a little more clearly Specifically how serious is this issue if an allowed service/driver list is not implemented for services.exe? And how could it be exploited with the current protection being offered for PG?
Hi Rerun, I'll do my best to explain the situation as I understand it (will somebody please correct me if I'm in error) ... Certain legitimate applications make use of services.exe to install drivers and/or services. Examples are the AOL client and part of the Norton Anti-Virus/Personal Firewall suite. So, in order for these legitimage applications to execute cleanly, services.exe has to be granted permission in PG to install drivers/services. However, this then leaves it wide open for malware to make use of services.exe to do the same thing. Of course, it has been said that for the malware to be able to do this, the malware application will, itself, have to gain permission to run, which PG should be able to intercept. Nevertheless, the request is that it should be made possible to specify exactly which services/drivers should be installable by services.exe, rather than a global "allow all". Seems like a sound enough request to me, but I can imagine that it'll cause quite a stir at DCS, since it does extend their model quite a bit, let alone the UI design to accommodate the extra layer of filter specification. Hope this helps ... I hope it's correct Chris
As stated by Andreas, such a layer is being worked on, . We have had much discusion on this subject and a possible methodology has already been defined by Jason, subsequent testing by DCS and the beta team will, hopefully, acheive a solution in the near future. Cheers. Pilli
Well Chris... that seems a pretty lucid and cogent explanation to me. When I first installed PG2 back last March, one of the alerts given was that two services/drivers (NAVEX and NAVENG)needed to be installed by Services.exe. Now, my knowledge of a lot of these things is pretty skimpy, but these two are Norton services/drivers and as far as I understand it are to do with updates. If I'm wrong, doubtless somebody will correct me. So, according to the perceived wisdom and Norton being a trusted app, I gave permission and left it at that.... So, for the last 6/7 months, Norton has been happy, but because Services.exe has had carte blanche to install services/drivers, this has left me (and everybody else in a similar position) to the risk of having trojans installed (which need Services.exe). So, all in all, there is the potential for disaster, although I personally wouldn't like to (indeed couldn't) quantifiy this. To sum up, I/we have the choice to have Norton happy and risk infestation, or stop any possibility of infestation and risk the problems of not having AV updates properly done. Its like being caught between the proverbial rock and a hard place. Now, I must stress this is how I see it, it is only my opinion and I'm certainly no expert, just concerned. I guess I'm setting myself up to be shot down in flames because I don't have the knowledge to quantify the risks. But obviously, giving Services.exe permission to install services/drivers when, or around when I think there may be a NAV update is ludicrous. Just hope it is not an unreasonable ask.. but I don't know. Hope this is a reasonably clear explanation... but others may wish to add/clarify.
Oremina, In the case of Norton and AOL allowing service /driver install does create a possibility that a Trojan could install a driver but fortunately that is not Process Guard's only defence, for such a driver to be installed a loading program would need to be run and you would get the checksumming pop up before such a program could run. Pilli
Indeed Pilli - and my Services.exe are still giving allow to services/drivers because I still feel very, very safe behind PG3. I do try to follow the proverbial "safe hex", don't really surf on the wild side, NEVER click on emails or anything I don't know and (at the risk of incurring somebodies wrath) use Firefox. So I don't really feel terribly threatened by trojans or much else really, I think it is more a case of hoping for absolute perfection in my number one protection, PG3. I haven't the slightest doubt but that it will get there someday and before very long. But no matter how small the risk of trojans is to me, there is still a theoretical risk which I would be happier without.
Oremina, I'm glad my explanation was of use. However, as Pilli quite rightly reiterated, even though NAV effectively forces to you to forego the layer of protection that PG offeres by denying services.exe permissions to install drivers/services, you are still not left unprotected. The checksumming feature should (if turned on) stop any malware from running in the first place. It's worth noting, however, that, without PG, both these layers of protection would be unavailable. Personally, I'd give NAV the elbow anyway. There are several alternatives which are better, cheaper, less resource-intensive and which don't rely on getting services.exe to install drivers on their behalf. I use a NOD32 / Outpost / TDS-3 / BOClean combination. They all update automatically, yet my services.exe has no permissions to install drivers/services. Indeed, the only program that has these permissions set is smss.exe (the Windows NT Session Manager), and I don't see a way around this one....anyone? Pilli, I'm glad that DCS are close to a solution on this matter. It will add yet another great layer of protection to an already excellent product. Chris
Hi Oremina As a beta tester and AOL user I eagerly await a beta to be able to test. In the interim as I have come to really understand the services.exe issue I don't like leaving it allowed. In the interim my solution(don't laugh) is to leave the install driver/services unchecked. Just before going online I check the box, start the log on and then uncheck it. Crude but it works for now. Until DCS works out the kinks on this issue you might see if a solution like mine might work for you. Pete
All possiblities are in the pot. My NAV subscription expires next March so I've six months to mull it over. Odd thing is, I quite like Norton, I'm just not very keen on Symantec.. Be a lot of head scratching around next March!!
I'm very encouraged that DCS is investigating/addressing the Services.exe issue. I'm confident that Jason et al will resolve it. Thanks much for the feedback and comments.
I'd say that from a technical perspective, (at least) two features are being worked on that are really spectacular. (That is improvement of Close Message Handling and service/driver installs via services.exe.) I'm amazed how clever the ideas are that Jason uses to come up with and how quickly he implements a first version to see if it is workable or not. But of course just having coded such a very first version means that there's still a long way to go. And I think it speaks for DCS's customer care and feedback awareness that they are working to include this although the next version actually was already in the high betas. But it also means that there will be quite a lot more to research, to code and to test before PGv3 goes final. I'm just hoping everyone will understand this. Andreas
I really hope that the extra layer of filtering that's being proposed for service/driver permissions isn't being restricted to just services.exe Surely, for any application that's being allowed to install services/drivers, the user should be allowed to select "all" (i.e. any services/drivers), or to be able to specify a list of allowed ones. ... or maybe that's what you meant anyway Chris
Hi ctc, Services.exe is a special case in that it allows other programs to load drivers / services (AOL & NAV for instance), most well written programs will write their own service / driver install routines, that is why services.exe is being treated differently. ie. There is the slight risk that a rootkit for instance could use services.exe to load it's driver. Cheers. Pilli