DiamondCS - Has PG's Protection been Compromised?

[Taz]

As a prospective customer of Process Guard, I find the report in this thread (http://www.wilderssecurity.com/showthread.php?p=412298) that the program's protection has apparently been compromised to be very troubling. I followed this thread from its inception thinking that any time now the vendor would jump in with an answer as to how this happened. Perhaps I've missed a report from them elsewhere? Has anyone heard anything from them as to how this happened?

If Adaware can find a way to terminate a protected process, I'm sure those that are clever enough to make use of advanced rootkits and other malware can find it too...especially now that it's been discussed openly on the net.

What is the customer to deduce from all this? Now that it has been compromised, does this mean PG is not worth purchasing?

Thanks,

-Taz

[amoeba]

This is troubling.
Is there more info on this?
Rich S

[BlueZannetti]

Well, I read that thread and frankly there's not enough information presented to render a verdict either way.

Clearly some users report termination of Spybot S&D by AdAware. That's an observation that is hard to miss, so let's assume it is absolutely correct.

Nobody posted any menu screen shots to provided explicit confirmation of the settings for both programs. The original poster does note that AdAware is set for read/modify, while spybot is set protected against termination and modification. Since AdAware is allowed to modify, that will supercede the protection against modification. Maybe it's tied up in this area, although termination clearly should not be the result.

Pilli's challenge confirmed the attempted termination, but termination was not successful in that instance. The original poster (vam) noted that he is using the free version of PG (see here (http://www.wilderssecurity.com/showpost.php?p=396043&postcount=18)) which is not quite as comprehensive as the full version. I haven't really considered the full impact of this on the oberved behavior.

Before I become worried about this situation, I would like a lot more detail behind the basic observations. I'm not saying the observations provided by the OP are incorrect, but there are gaps that would prevent me from fully analyzing the situation. I'd specifically focus on some of the areas left unguarded by the free version (e.g secure message handling, etc.) that may be pertient.

As to your main question - is PG worth purchasing - I'd give that an unqualified yes. That's an impression as a user. The current version works seemlessly on my system and at a default configuarion level functions quite well. The unlimited home license is well worth the expense IMHO.

Blue

[Peter2150]

I totally agree with Blue's observation.

Pete

[gottadoit]

I agree with Blue it is a very useful program that is quite easy to use and provides a very good security layer without adding too much complexity.
Certainly something to strongly consider purchasing, the cost would easily be saved in your time if it blocked a rootkit trying to install a driver...

There are some other *small* issues that have been discussed in the PG forum that mean that PG has some *potential* problems. If some actual evidence of process termination surfaces (other than by window messages when the app is not protected by SMH) then by all means take it seriously (in the mean time keep watching the thread..)

The *potential* problems are not such a big deal if you are willing to deal with the additional complexity of a few more prompts and forcing yourself to read and understand the contents of each allow/deny prompt each time....

Andreas1's sticky thread summarises the potential issues quite nicely

Secure Message Handling has been discussed in the ProcessGuard v3.xxx Suggestions / Wishlist (http://www.wilderssecurity.com/showthread.php?t=53279) thread, a variety of different suggestions have been put forward to help deal with dialog boxes etc. The current implementation is a little cumbersome but it is a lot better than having nothing

One other one I am aware of is that you can bypass the GUI prompt during startup and get something happening with "permit-once" privileges fairly easily if you have a slow machine or a machine bogged down by Disk IO during startup.
To avoid this use a startup manager for most of the non-security apps and leave your security tools as registry startups to make sure they get started and initialised before anything else

Another issue and this is not strictly a problem with ProcessGuard but another attack vector that you should guard against is unwanted entries appearing in your startup sequence... Another unwanted program could disable ProcessGuard by starting before it does and stopping it running (in a variety of ways)

As you are probably already aware, you need some sort of registry monitoring tool to guard against some malware targeting ProcessGuard. ProcessGuard will stop unauthorised programs starting by prompting you once it has finished initialising, but before that its on for young and old...

As many people have said before me (and undoubtably will continue saying) if you get your programs from trusted sources then you are less likely to be exposing your computer to problems in the first place and the issues I'm mentioning above will simply not matter

[Taz]

I would agree that controlled tests followed by screen prints of settings and whatnot would be a better indicator of a security lapse. Still...the original user's report was followed up by someone else (Rodehard) reporting the same behavior. He at least attempted to document his findings with a posting of his log that says Adaware was prevented from shutting down Spybot...yet his observation was that Adaware did indeed terminate the program.

I think it would be highly unlikely for separate and (I’m assuming) independent users to have ulterior motives for reporting the behavior they observed. Therefore I'm forced to conclude that their observations were correct. However, as has been pointed out, a possible explanation for this apparent security lapse could be tied to user configuration errors. (The trial vs. full-featured programs explanation seems to have been negated by Rodehard's assertion that repeated tests were done with secure message handling enabled for Spybot...an indication that he had the full-featured program.)

While user configuration error is a plausible explanation, an equally plausible explanation is that Adaware used an undocumented method within Windows to terminate the protected program. Considering the almost daily findings of new security holes within Windows, it would tend to make one gravitate to the latter explanation rather than the former.

But once again, without controlled testing both explanations at this point are pure conjecture. This is why I was hoping DiamondCS would have responded the questions raised. It has been sometime now since these questions were raised in the original thread (and now this one) and the issue still goes unaddressed. I find this to be as troubling as the protected program termination behavior that was originally reported.

[jimmytop]

-{ Quote: "
But once again, without controlled testing both explanations at this point are pure conjecture. This is why I was hoping DiamondCS would have responded the questions raised. It has been sometime now since these questions were raised in the original thread (and now this one) and the issue still goes unaddressed. I find this to be as troubling as the protected program termination behavior that was originally reported." }-

I agree - DiamondCS should be looking at this to duplicate the issue and fix it, in their own closed lab environment. But, maybe DiamondCS doesn't read this forum? Did anyone email them directly?
I'll admit, DiamondCS's response time for me has been less than spectacular, but has the issue at least been brought to their attention (not in these forums, because they may not be reading them - but thru email instead?).

On the other hand, I still have unresolved issue that DiamondCS simply won't respond too. I just [sigh] and live with it.

[gottadoit]

Taz,
I wasn't suggesting that ppl making the reports had ulterior motives, if I see something that looking like trolling I just ignore the posts.
From re-reading the thread I see now where Rhodehard suggests that he had enabled SMH and made repeated attempts...
-{ Quote: "-{ Quote: " Before you update the definition file in Ad-Aware try running the test with Secure Message Handling enabled for Spybot and see if that changes the outcome." }-Too late, I updated and fixed the issue. But I did test it several times with secure settings and Adaware blew away PG each time. I shouldn't have to experiment with CMH, its cumbersome and not user friendly." }-
If SMH was enabled for SB S&D when the app was running then the first kill could be explained away but not a second, time for me to actually try it and see what windows messages (if any) are being passed I think

As far as DCS and their lack of response, they do read the forums but remember if they joined in the conversations too often they would have even fewer deliverables

I'd suggest emailing the support address after all that is the way to get support, the forum is an added bonus

[Mephisto]

I bought a full copy about 5 weeks ago.
I must say if i had known about this issue back then i would probably have not done so. This is the very core and essence of what this program is supposed to protect you from - if it doesn't work properly then it's of no use to anyone (at least not to me).

If this does become a trend and PG can be derailed at will by other programs then PG will have been big waste of my money and an even bigger disappointment.

Time will tell.

[Taz]

-{ Quote: "Taz,
I wasn't suggesting that ppl making the reports had ulterior motives, if I see something that looking like trolling I just ignore the posts.
" }-

Oh absolutely, Gottadoit...I totally understand that's not what you were suggesting at all. Forgive me for my poor way of putting things. I was just trying to do the classic "If A, then B, = C" logic type trail.

And I do think you and the previous poster are correct. Perhaps this is something that would warrant an email to DiamondCS. Being somewhat new around here I thought they monitored this forum a little more closely than what they do. However, I should've remembered that small businesses have a hard enough time running lean and mean as it is and don't have unlimited resources to follow every thread.

I'll do my best to drop them a line here in the next day or so and report back with any response I might receive.

-Taz

[Simon Says]

-{ Quote: "Well, I read that thread and frankly there's not enough information presented to render a verdict either way." }-

C'mon guys, why would these users (registered i might add) come on this forum and make up a story like this? They were correct in the other half of their story about 180 Solutions. Sounds like some PG fans don't won't to admit that not everything DCS turns out is made of gold.

And this is the breath-taking technology that put TDS-4 on hold for so long? What a shameful exhibition. The reason no DCS personel have weighed in on this is because they basically have nothing to say that can defend PG, other than Lavasoft's programmers are obviously better than DCS's and thanks for the 30.00 bucks.

[Pilli]

-{ Quote: "if it doesn't work properly then it's of no use to anyone (at least not to me)." }- This assumes that there is a possibility that ProcessGuard has a flaw, no program is perfect but there has been no valid fault found by an expert to verify such a claim. If this is indeed a flaw it does not invalidate PG's value that much as PG adds whole host of security measures to your machine.
There is NO program made that can promise 100% security, DCS has always maintained that ProcesGuard is just one part of your defences albeit a very strong part. I for one would forgo all my other security programs given the choice of only one security program. :)

Pilli

[Rodehard]

Hi guys
I have been following this issue since the previous threads came out after Jason released the two tests. I was quite upset that my PC failed and further that the why of it was not explained. As I recall Jason did indicate that they finally reproduced the failure and that a fix was in the making. However, I'm still out in the cold as to why my test failed and what I might do about it other than wait for the fix. I mean, if its now known why some failed why not tell me how to fix my configuration???
On the Prevx board
http://castlecops.com/postt112062.html
it seems that running that particular test from the desktop ??? is the secret. I'm assuming that something like that is in play with the PG test and Jason doesn't want it broadcast to the world until he issues the fix. Because of this I have restrained myself from making a big deal out of the issue on the board but am keeping an eye out for further revelations. I did purchase RegDefender and will continue to use it along with PG, Prevx, Outpost and KAV 4.5 because I feel they are quality products. But, for now, nothing gets run from my desktop.

[gottadoit]

Does anyone have the adaware defn file SE1R30 08.03.2005 ?

I am going to use WinSpector to see if the termination method is actually sending window messages... in case anyone else wants to do it themselves (www.gipsysoft.com (http://www.gipsysoft.com/) or the actual home page for the app is www.windows-spy.com (http://www.windows-spy.com/))

Its not a particularly hard application to learn how to use, there are probably other better ones out there but it looked ok when I went searching around, I'll happily accept any suggestions for better tools :-)

The next step after that is WinDbg I suppose or maybe one of the noddy API monitors ....

NB: In the lavasoft forums it was mentioned that the false detection problem was fixed in the SE1R32 10.03.2005 update (see thread on lavasoft board (http://www.lavasoftsupport.com/index.php?showtopic=60373&hl=))

[Pilli]

RodeHard, Your post is not relevant to ProcessGuard but the the PrevX flaw, unlees, of course, your link was incorrect. The prevx problem can only be solved by the developers which they say will be implemented for the next release. :) Jason's forums are below as he is no longer working for DCS.

Please remove your post if this is the case.

Pilli

[Rodehard]

I'm aware of who's on first this week. I was referencing one to possibly explain the other. So far, its the only theory I have as to why PG, RD and Prevx all failed the RegTest on my system.

[Pilli]

-{ Quote: "I'm aware of who's on first this week. I was referencing one to possibly explain the other. So far, its the only theory I have as to why PG, RD and Prevx all failed the RegTest on my system" }- The PrevX vulnerability test is not the same as RegTest - Regtest will close any computer down as it uses End Session to do that, regtest tries to modify certain registry settings and if successfull displays a box after reboot. If not your reboot should be normal.

ProcessGuard does in fact stop the test from running unless you specifically allow it so no vulnerability there:)

HTH Pilli

[jimmytop]

-{ Quote: "I'm aware of who's on first this week. I was referencing one to possibly explain the other. So far, its the only theory I have as to why PG, RD and Prevx all failed the RegTest on my system." }-

Process Guard is not a registry protector. It is not intended to stop the kind of attacks that Regtest.exe simulates. It's like asking Windows Media player to defrag your hard drive. It's the wrong tool for the wrong job.

If you have problems with Regdefend and Prevx failing Regtest.exe, then you should try posting those problems in those software's appropriate forums.

This thread was originally started to report concerns with a specific case where Adaware SE allegedly was able to terminate a process that was under the protection of PG. Not sure how PG failing Regtest.exe has anything to do with that....

[earth1]

-{ Quote: " ... The original poster does note that AdAware is set for read/modify, while spybot is set protected against termination and modification. Since AdAware is allowed to modify, that will supercede the protection against modification. Maybe it's tied up in this area, although termination clearly should not be the result.
Blue" }-
Blue's point quoted above may be a very relevant issue here. I suspected similar issues when someone reported that EndItAll (PC-Mag utiltiy) was able to defeat ProcessGuard in this thread with DCS participation (http://www.wilderssecurity.com/showthread.php?t=55387) . My tests seemed difficult to duplicate, but my final (unverified) conclusion was that giving EndItAll permission to modify PG-protected programs enabled it to terminate many protected programs. At least on my system, that ability seemed independent of the SMH issues. If anyone is still set up to test the faulty version of AdAware, I'd suggest removing its permission to modify protected apps and see if SpyBot gets terminated.

A second thread (http://www.wilderssecurity.com/showthread.php?t=55744) touches on the issue of limiting the number of programs allowed to modify other PG-protected apps. I am guilty of not updating my own thread, but my (unproven) conclusion is that while many "normal" applications will run fine without permission to modify, security applications should be allowed to modify PG-protected programs.

Since AdAware is a security program I'd recommend permission to modify, but since its developers have proven themselves trustworthy, a bug in AdAware is not the same as putting malware in the driver's seat. If you download some malware and run it AND tell PG to let it run AND tell PG to protect it AND tell PG to let it modify protected programs, THEN you may have a problem. It's not really fair to fault PG for trusting a program in the ways it is instructed to do so. However, I'd agree that the modify/terminate issue should be cleared up if it truly exists.

I agree that more DCS participation would be a good thing, but I think they are behind on other committments and shorthanded at the same time. Fortunately, there are longtime users that do try to duplicate reported problems. It's a time-consuming and frustrating job. Inevitably, it makes more sense to expend that effort when the initial report seems thorough and well documented.

Progress may be slow, but I don't think it has stopped. I agree with the others here that PG is far from perfect, but it does address more of Window's truly thorny problems than anything else I've found.

[Rodehard]

Sorry, I hop around these boards and it all starts to run together. The original issue was with adaware killing SB S&D despite PG protection. At the same time regtest came out and blew away RD and in doing so terminated PG and Prevx. Both, I mean all, of which were protected by, well sort of, PG. The only mitigating factor is that I did have to allow the test to run in the first place via PG thus confirming that, at least, component control worked if not termination protection. When I say protected by I mean that termination was protected against and the offending application/test did not have termination nor modify rights. I watched the PG log in real time as it claimed to have stopped SB S&D from being terminated while SB was in fact terminated. I then watched as the Regtest allowed all my security apps to be closed down, including PG, despite termination protection.
PG, RD and Prevx are the core of my defenses but, foremost is PG. So, in my mind at least, this string of events very much pertains to PG when viewed as a whole. For me the question still remains as to why PG failed in this way. I thought this was germane to the original posters question since he alluded to the thread whereby adaware was able to bypass PG.
As for the rest of it you are right, I should take it to the diamond cs board. I read Jason here enough that the lines have blurred. :)

[rickontheweb]

Interesting discussion.

I do want to remind everyone that that are numerous settings that can change the outcome of any termination attempt in PG, as others here have stated. You can also have the best firewall in the world, but if configured wrong or settings are configured liberally to provide an easier user experience, well stuff happens ya know.

I think Earth1's mention of EndItAll2 was a great example. When I first tried it back in November, it terminated everything except my antivirus and firewall, using the older version of PG running using out of the box settings. I was disappointed. But that only made me realize the default settings aren't the securest settings.

I have since upgraded PG and scaled back settings and application rights severely. Nothing gets modify or read rights unless it's a security app or core windows component and every possible component of security related apps gets protection from being read. Nothing is allowed to install diddly squat or access physical memory unless it's security related or literally breaks/crashes the application.

I got much different results this time. First off, NONE of my security apps or related components even appeared in EndItAlls list to be terminated. It couldn't even see them at all and of the remaining things it did see, it terminated only 8 and they were relatively unprotected Desktop GUI addons like a Calendar, ToDo and Dock program. It couldn't kill any windows processes or even see the security related stuff running. And I do not even use SMH at all.

It's important to remember with security software that the learning mode, allow everything what it wants, use default settings approach, is made to guarantee compatibility and ease of use while providing a decent measure of protection.

It you want PG to lock down your system further, you have to scale back rights and test, since every system and user is different. It can't do that out of the box. But even still, this is a relatively new approach to security for windows, and security is always a cat and mouse game. There are no absolutes in Windows; we should all know that by now. That's why software's always getting upgraded, patched, and signatures come out almost daily, etc.

[Peter2150]

I've been watching this thread with interest, but so far have not entered. But a thought occurred to me earlier. If I remember right some earlier defs in Adaware caused an entry in a PG log saying an attempt was made and blocked to shutdown Spybot, and then it shutdown.

The problem well may be the assumption, that it was indeed Adaware that shutdown Spybot.

We have all seen software that asks permission to modify or terminate something and PG blocks it, often with no ill effect. Also if we give that legitmate software the privileges it seeks, it doesn't actually do a terminate, but was just testing for the privilege.

Secondly I've seen other things shutdown software. Every now and then I'll see a program that running just plain disappear. No crash no message, just gone. Then I quit messing with the system and these events stop. As it is they are infrequent. (my machine IS clean). Then there are interactions where two programs aren't happy at certain interactions. For example I also run DCS Wormguard. If I forget to to shutdown the wormguard protection when I am installing a Zone ALarm upgrade, the upgrade process gets so far, stumbles, and then crashes off into the sunset. BUt if I turn off wormguard, the install goes fine, I then turn wormguard back on, and they both are fine.

Point is Process Guard can only prevent termination, IF the termination is being caused by program A issuing some windows call that allows it to terminate program B. But if some other collision by Adaware with those defs brings Spybot down, then PG couldn't be expected to stop it.

So the real question is what actually happened. Did PG block a request for termination and then allow a legitimate termination effort to succeed, or was there some other mechanism that brought Spybot down.

If I were to bet, I'd bet it wasn't PG, but thats just me.

Pete

[Gavin - DiamondCS]

Any termination which succeeds like the case which was discussed, will be a Windows close message, this has been discussed many times. If you want to protect against a simple attack like this, you can do so. It is really not an issue to worry about at all. It is not an attack method any malware uses. I see hundreds of malware a day. None of them can terminate PG, or terminate a PG protected application.

The program was never meant to be a registry protector or anything else, it does its job 100% as it was intended to do. There is no reason to worry and PG has NOT been defeated in any way. Remember - Pilli tried to reproduce the problem and the termination did NOT succeed.

[Taz]

-{ Quote: "Any termination which succeeds like the case which was discussed, will be a Windows close message, this has been discussed many times. If you want to protect against a simple attack like this, you can do so. It is really not an issue to worry about at all. It is not an attack method any malware uses. I see hundreds of malware a day. None of them can terminate PG, or terminate a PG protected application. " }-

Gavin - Thanks for stopping by to comment.

However, I still don't quite understand. Exactly how did Adaware shutdown a protected program? Are you saying it did so by simply causing a Windows close message? Also...if Adaware can do it, doesn't it seem reasonable that malware writers could do it also? Forgive me, but just because you haven't seen malware written this way so far, isn't it possible it could be written this way in the future? If it was easy enough for Adaware to do it, doesn't it seem reasonable to expect that it will only be a matter of time before malware writers also do it?

On the other hand, if you're saying there's a way to configure PG so this doesn't happen, please tell us how we should set things up. I don't believe Pilli had everything necessary to duplicate the behavior that has been reported. If you can advise us on the proper way to set things up so this doesn't happen, pehaps someone with the old Adaware file can re-run the test and report back.

Thanks.

[Infinity]

-{ Quote: "However, I still don't quite understand. Exactly how did Adaware shutdown a protected program? Are you saying it did so by simply causing a Windows close message" }-

I don't know what's the fuss here: let me explain :) adaware has the termination privilege right? cause it is a security program it needs in certain cases termination privileges...cause terminating the malware must be possible...through PG in our cases!

however in this case is adaware terminating another (good) process ::)

-{ Quote: "Also...if Adaware can do it, doesn't it seem reasonable that malware writers could do it also?" }-

Only if you accept the starting up of this malware through PG and only if you give the malware the termination privilege ;) c'mon guys...

-{ Quote: "Forgive me, but just because you haven't seen malware written this way so far, isn't it possible it could be written this way in the future?" }-
yes off course it can, everything will be possible in the future...who knows? But DCS allways released a fix, very quickly... there's no doubt bout that.

-{ Quote: "On the other hand, if you're saying there's a way to configure PG so this doesn't happen, please tell us how we should set things up." }-

just don't give every program termination protection, this advice is allready offered...

-{ Quote: "It's important to remember with security software that the learning mode, allow everything what it wants, use default settings approach, is made to guarantee compatibility and ease of use while providing a decent measure of protection. " }-

-{ Quote: "Since AdAware is a security program I'd recommend permission to modify, but since its developers have proven themselves trustworthy, a bug in AdAware is not the same as putting malware in the driver's seat. If you download some malware and run it AND tell PG to let it run AND tell PG to protect it AND tell PG to let it modify protected programs, THEN you may have a problem. It's not really fair to fault PG for trusting a program in the ways it is instructed to do so. However, I'd agree that the modify/terminate issue should be cleared up if it truly exists." }-

no need for old adaware signature files... ::)

[Taz]

-{ Quote: "I don't know what's the fuss here: let me explain :) adaware has the termination privilege right? " }-

No...not at least as reported. And that is what the fuss is about.

Quoting from the orginial message: "adaware is authorized to read and modify. spybot is protected from termination and modification (except from this killer version of adaware)."

Granted, as a prospective user I don't know PG as others do, but I took the above statement to mean that termination authorization had NOT been given to Adaware...only read and modification rights. I think this was the same configuration the second person in that thread reported also.

IF (and that's a big IF) the configuration was indeed set this way, then the original question remains...how did the termination happen?

[Infinity]

-{ Quote: "IF (and that's a big IF) the configuration was indeed set this way, then the original question remains...how did the termination happen?" }-

Don't know and would be indeed another thing to discuss...I think I understand the while issue now :)

Anyway to reproduce this "possible error/bug/situation" is indeed harder then it looks like in this case and I will follow this thread very closely cause I would like to know the outcome :) now matter what the cause will be.

Will it therefore be exploited? Possibly :)
Will DCS release a fix if needed? Probably fast enough, they allways done it in the past too 8)

cheers

[earth1]

There is also evidence in Pilli's log posting (http://www.wilderssecurity.com/showpost.php?p=394166&postcount=3) indicating that AdAware did attempt to "terminate" Spybot on his system (but was not successful). Pillli did not report having to Cancel at an SMH/HID prompt and Rodehard did enable SMH but didn't see it triggered, so "use SMH" does not sound like the whole story either.

I, too, would like to encourage anyone who is still set up to test this.

[Rodehard]

Let me set my half of this to rest. I can not honestly say that adaware did not have termination rights the first time it shut down SB S&S. For reasons mentioned by several posters it would have been my habit to give it that right but, I had been trimming the list of apps with termination rights just prior to that (for the same reasons mentioned by several posters) and its possible adaware made the list. So, I give you that point. However, after the first instance (and finishing my cup of coffee) I very deliberately confirmed that adaware had no mod or term rights and that SB S&D was protected from termination. SB S&D was still terminated by adaware the two or three times I tested. After that I updated adaware and the problem was resolved.

I have been around computers for too long (first MCSE cert in 95) to panic over this and experience has taught me that most problems are caused by the lose nut behind the settings panel. I still would not trade PG for a free licensed copy of the protection suite of your choice. Faith only slightly shaken I still highly recommend Process Guard along with RegDefender as must have first line of defense protection.

[Peter2150]

Hi Rodehard

A double amen about PG. I wouldn't give up PG for anything.

Pete

[Taz]

-{ Quote: "However, after the first instance (and finishing my cup of coffee) I very deliberately confirmed that adaware had no mod or term rights and that SB S&D was protected from termination. SB S&D was still terminated by adaware the two or three times I tested. After that I updated adaware and the problem was resolved." }-
It would seem, then, that unless and until DiamondCS can give a direct explanation as to why this happened and/or offers a patch, one can only conclude that the program will not keep a protected application from terminating in all cases.

I for one do not think this is necessarily a black mark on an otherwise excellent piece of software. However as history has taught us, a black mark (in the eyes of the customer, that is) could result if DCS mishandles this issue. By mishandling I mean by refusing to directly address it, or by refusing to address it honestly.

If they don't already know what caused it, I am quite certain they could obtain the Adaware defininition file from someone in their user base and attempt to replicate the problem. Doing so and then honestly reporting their findings would help retain the value in their product that they have worked so hard to build. If it turns out there is a security hole, then by admitting it and then plugging it will only result in increased value.

But saying a vulnerability doesn't exist because no malware to date has done what Adaware did is circular logic at it's best and an attempt at burying one's head in the sand at worst. I think DiamondCS' customers deserve better than this.

[Rodehard]

My thoughts exactly. Even if to say they simply can not reproduce the results. Considering the apparent rarity of my experience I'm willing to believe it was a simple fluke. 8)

[Taz]

I think reasonable people would agree that no matter how well written or designed, an occasional program anomaly can occur. However, your repeated tests plus the report of another independent user experiencing the same behavior doesn’t quite fit the common definition of a “fluke”. Barring some as yet forthcoming explanation from DCS, it would seem to point instead to a vulnerability within the program.

[Pilli]

When I tested at the time I could not reproduce the termination , a few things come to mind.

Sometimes changing the termination settings or any other settings on a service or driver require a reboot to initiate the change correctly and or a restart of the protected process.
Giving termination abilities to a protected programm will allow it to terminate any other program on the protected list, this should not normally be necessary as protected programs are trusted and verified at each start up by their checksums, your security applications can still terminate malware ie. anything that is not on the protected list.

Changing an applications protection criteria may have deleterious effects which can be instantly noticeable or only become obvious over a period of time dependent upon interactions with other programs or system operations, Global hooks being a contender here.

In addition SMH needs to inject procguard.dll into the process, this will not usually occur until the process is restarted. Using a utility like Process Explorer or Faber Tools will show that injection has occurred correctly.

As said earlier this condition has not been verified as a vulnerability by any expert source and beleive me there are many experts trying to find bugs in programs such as PG, these experts are not all hackers or crackers and so far there are no reports of vulnerabilities in this build, having said that it will only be a matter of time before something is found as with any other software.

Just my view :) ProcessGuard is a very powerful tool and has almost infinate possibilties. It is not perfect and nor is ANY other program

Pilli

[earth1]

Pilli, your experiences throw some more light on what could've happened in testing EndItAll. Thanks for the input (but all those reboots sound daunting). :)

Taz, the more time you spend here you'll likely find an increasing sense of complexity around the question of "what really happens". I'm sure DCS has been asked to slay many dragons that didn't really exist, but's it's no easier for them to prove that the dragon doesn't exist than it is for us to prove it does. I think the burden of proof has to lie with us, but sometimes I do wish there was a bit more "process". ::)

You've already managed to focus an unusual amount of attention on this issue, so I hope it's possible for you to continue persuing these questions. I think you've seen a pretty good demonstration that, while opinions vary, most folks here do openly encourage discovery, wherever it leads. Before investing the effort, though, be aware that it may produce frustration on all sides. I think that's why Microsoft and Symantec won't even acknowledge our existence much less our problems. Remember too, DCS has immensely fewer resources to divert than what the big boys have.

Best regards.

[Pilli]

-{ Quote: "Thanks for the input (but all those reboots sound daunting)." }- This is, of course, related to the hardening process which does require operations at the lowest system level, as you say the "discovery" approach can mean a considerable amount of work by the user especially if one takes into consideration that every user's machine has a different configuration.

Regarding DCS testing such unknown entities, I would rather they used their limited resources to complete TDS4 at the moment.

Fortunately we can learn from each other's experience which, IMHO, is one of the great benefits of discussions such as this in these forums. ;D

Cheers. Pilli

[earth1]

Pilli, I agree with both your observations and your priorities. Thanks for "being on the job" ... and belated congratulations, Mr. Global Moderator. :)

[gottadoit]

We could always just ask Corrine (http://www.wilderssecurity.com/showpost.php?p=395709&postcount=13) how AdAware attempts to terminate applications, you never know she might just answer and that would be the end of it....

Otherwise I have PM'ed VAM and asked him for the definitions file (or if anyone else fronts up with it) then I can do a test and make the file available to DCS and anyone else from Wilders either known to me (or with decent creds based on what they post)

Speculation isn't going to solve the argument one way or the other
I think that Gavin's response was indicative of frustration as much as anything else, valid criticisms have been raised about SMH but TDS4 obviously needs to come first....

[Taz]

-{ Quote: "Taz, the more time you spend here you'll likely find an increasing sense of complexity around the question of "what really happens". I'm sure DCS has been asked to slay many dragons that didn't really exist, but's it's no easier for them to prove that the dragon doesn't exist than it is for us to prove it does. I think the burden of proof has to lie with us, but sometimes I do wish there was a bit more "process". ::)

You've already managed to focus an unusual amount of attention on this issue, so I hope it's possible for you to continue persuing these questions. I think you've seen a pretty good demonstration that, while opinions vary, most folks here do openly encourage discovery, wherever it leads. Before investing the effort, though, be aware that it may produce frustration on all sides. I think that's why Microsoft and Symantec won't even acknowledge our existence much less our problems. Remember too, DCS has immensely fewer resources to divert than what the big boys have.

Best regards." }-

Thanks, Earth1. I have indeed noticed that folks around here openly encourage discovery. It is both refreshing and encouraging seeing such an atmosphere instead of one in which discussions deteriorate into ego defenses and whatnot.

And...I do have great empathy for small businesses that face the tough decisions on the best way to allocate scarce resources. If they go tilting at windmills there's the danger of losing their core focus. I would also give the point that it's entirely possible that all this is much to do about nothing.

However, please consider the other side of the coin...that of the consumer in trying to make a purchase decision. In evaluating whether something “works” as advertised or not, the consumer most often does not have perfect knowledge. The consumer often has to rely on anecdotal evidence (e.g., word of mouth). Such is the case here.

While reliance on such reports is not ideal, in this case it’s all this consumer has to go on. As questions to the vendor on their own support forum have largely gone unanswered, there is no other explanation to hang my hat on. I had hoped to hear that the program was not configured correctly. While that indeed may very well be the case, we apparently will never know.

That said, I would like to put my questions to bed. I’ve invested enough time and energy in my purchase decision. While I think for the most part that IF there is a vulnerability, it would take awhile for most malware writers to target, or even discover it. However, for myself and for the installations I have budget authority over, barring some new information I simply would prefer not to take that chance.

My thanks to all that participated in this thread.

[Peter2150]

Hi Taz

Just a quick comment. Everyone has to base their own decisions, on what is best for them, but just for a moment consider the protection that Process Guard has proven to provide, and weigh that against the small possibility, that there may be a flaw. Also consider other solutions to provide the same protection, and how do you ensure that there isn't some flaw there.

Pete

[Gavin - DiamondCS]

Just a quick word that close messages are suspected, and that this protection method has many quirks. We _may_ look at this again, but the key to close messages are that they ONLY work on a window. Any really REALLY critical program such as an antivirus scanner can never be vulnerable - it is implemented as a driver and service both of which have NO window at all.

For this reason, the "attack" has always been low risk, no matter what might APPEAR on the surface to be dangerous in some way. All we ask is that the users have faith that we know what we are doing. You are not going to have your AV shut down like this, and malware writers know better than to waste their time closing GUI's. They prefer to develop stealth trojans, more advanced firewall bypass, work on social engineering techniques, new packers with anti emulation, complex kits with legit tools that AV's dont detect, and practice their trojan hex editing.

If you use Close message handling, something to be aware of is that messages are held in limbo when you see the message box. In the case of this situation, they can be prevented by NOT pressing either OK nor cancel, until the attacker (AdAware in this case) has given up. Then, the termination does not succeed. There is hope if we further develop this protection, but for the reasons above its very doubtful we ever will need or want to..

Hope that helps :)

[BlueZannetti]

-{ Quote: "If you use Close message handling, something to be aware of is that messages are held in limbo when you see the message box. In the case of this situation, they can be prevented by NOT pressing either OK nor cancel, until the attacker (AdAware in this case) has given up. Then, the termination does not succeed. There is hope if we further develop this protection, but for the reasons above its very doubtful we ever will need or want to..

Hope that helps :)" }-For those users who do not have access to the dated AdAware definitions file to specifically test this situation (I do), just a short comment to confirm that the problem develops and is resolved precisely as Gavin describes. Personally, I do not view this as a serious issue.

Blue

[Gavin - DiamondCS]

Special thanks to Blue for going to the trouble over the last few days, and then letting me know about this. Thanks !

[gottadoit]

-{ Quote: "For those users who do not have access to the dated AdAware definitions file to specifically test this situation (I do), just a short comment to confirm that the problem develops and is resolved precisely as Gavin describes. Personally, I do not view this as a serious issue.

Blue" }-
Blue,
Thanks for doing it seeing as you had the file, now in the spirit of learning I've got to ask how did you check to see what was going on ?

[BlueZannetti]

-{ Quote: "Blue,
Thanks for doing it seeing as you had the file, now in the spirit of learning I've got to ask how did you check to see what was going on ?" }-I performed challenge/response testing. I first had to secure an old copy of the definitions file - it seems as though a number of Asian servers store copies rather than links, a google search and 15 minutes of time and I had the appropriate file. I first tried to replicate the observations originally noted (http://www.wilderssecurity.com/showthread.php?t=69837) by vam. I could replicate everything noted there: the message that PG had blocked termination, and then the subsequent termination of Spybot.

Focusing on SMH was simply a consequence of walking through the possible scope of items where control and blocking could be achieved. When I did this I noticed that if you let the windows message queue sit, and wait for AdAware to finish (but keep the AdAware application active), Spyboy S&D is fine. If you then start to clear out the windows message queue by cancelling out the successive human verification windows which appear, you can see where the termination occurs. If you do this slowly, you will find:
WM_CLOSE appears, S&D is fine, cancel and
WM_DESTROY appears, S&D is fine, cancel and
WM_NCDESTROY appears, S&D is fine, cancel and Spybot is killed and
WM_DESTROY appears again, cancel
WM_NCDESTROY appears again, cancel
OK, Spybot is terminated, but it is clearly tied to termination messages at the windows level. Rather than keep AdAware active while you go through this successive cancellation of messages, wait for Adaware to finish and then close it out before doing any cancellation of the human verification messages. Only the first message cancellation is needed, there are no human verification follow-ups, and Spybot S&D survives fine. The windows message queue is cleared by the termination of AdAware so the offending message never gets processed.

That's really all I did. I'm not a programmer, so don't ask about a nuanced interpretation because I can't provide it. You can also prevent termination by blocking the ability of applications to read Spybot, but that's a messier solution due to all the messages generated.

As I noted, I don't view this as a pragmatic operational issue.

Blue

[gottadoit]

Blue,
Thanks for that, it is what we are all here for after all

I suspect your post will do a lot more than putting peoples minds to rest about this particular issue, it will give people a starting point to learn about what is going on behind the scenes with windows messages and thereby raise the "bar" on the debate about SMH

It is very interesting to know that DCS didn't consider SMH a "core feature" of PG. I'm glad it is present for the obvious reasons of preventing termination of non-core security applications. It would certainly be nice to see this area of PG refined and expanded upon in future versions

Out of interest what tool did you use to observe the windows messages ?
(I know there are a few out there...)

[BlueZannetti]

-{ Quote: "Out of interest what tool did you use to observe the windows messages ?
(I know there are a few out there...)" }-I used PG itself, via the human confirmation dialog boxes. Just set the secure message handling flag for Spybot.

Blue

[Rodehard]

Good job, thanks. :-*

[rickontheweb]

Perhaps a different way of handling SMH/CMH could be implemented or considered at some point down the road?

What if there was another option - No Close Message Handling, where instead of placing close requests on hold and prompting with SMH, they are simply filtered out and denied altogether if this option is enabled for the process. It could be used for security based GUI based windows we don't want to close down.

Of course how do you close the app if you really need to close it or need to reboot/shutdown? It could be tied to a reboot/shutdown prompt, click no, nothing changes and no reboot/shutdown, click allow and globally "No Close Message Handling" is disabled to allow the machine to reboot or shutdown normally. Optionally you could go in and manually turn off No Close Message Handling in the PG Protection tab settings for the app in question to allow it to close without rebooting.

It would be a nice solution for always running security applications that have a GUI component you really don't want killed and for those that do not want to bother with SMH prompts, while giving us some reboot/shutdown control as well.

[Peter2150]

Hi Blue

Nice piece of detective work. Hopefully it puts some uneasy minds at rest.

Pete