Set to Permit Once

Like they say on the financial markets, past performance is no indication of future performance....

This seems to have identified a small and occasionally viable window for malware to make system changes, I am sure there will be other similar ones
Protecting the system from registry changes is not what ProcessGuard does
[it actually does for one key, see the registry monitor comparison thread ]

The issue here is that PG could do with being a bit more aggressive at system startup time and try a bit harder to possibly avoid the race condition rather than just try hard to get there first...

The other big flaw is the behaviour of allowing programs to run once during startup without authorisation, it is quite possible that the program that got into your startup sequence would not have been allowed to run if this were the case

Andreas1 mentioned that DCS and the Beta testers tried hard to think of as many holes (even theoretical ones) so that there would be less criticism of PG 3 when it came out.
Its a good product, but the startup issue is a gaping hole and the other sideline issues like that with rundll32 degrade the solution a bit more

My point really was that just like the rundll32 issue, this one has been exploited once and given that the same or similar techniques could be used to remove PG from starting. The attack vector that the malware arrives on will probably be different, but at least one malware writer has code that can stop PG starting (at least some of the time) and could easily share it with others

 

Its hardly a gaping hole, PG was never designed to do "everything". It will prevent direct attacks as used in so many areas of malware. Most important it will ensure any firewall becomes FWBypass proof (with all firewall allowed processes protected )

 

This should be fine as it is triggered by SnagIt from TechSmith.

Thanks,

Chris

 

Gavin,
I agree that PG is good enough for most threats right now and better than having nothing at all. If I haven't said it recently I'll point out again that I like PG and I think it is a good product. Thanks for the insight into what you expect from the product it is very useful to know

I'm happy enough that you have listened and responded, mostly because I think you will at least consider what has been said. I hope you take the comments in the spirit that they were offered, and that is to make PG an even better product at what it already does and polish off a few rough edges ;-)

I disagree that I am referring to something here that falls in the realm of "everything", this is basically a difference between advertised behaviour (from the website and in the help) and the actual behaviour in the enforcement of execution protection
Just by reading the statements on the website, I could easily think that I could use PG to control what is being executed and not realise that other executables that have not specifically been allowed can potentially be run during login

The design decision to do this was unfortunate because it opens a window of opportunity which apparently one bit of malware has exploited

As to whether the hole is a gaping one or not.... thats a matter of opinion on which we currently differ, thats not a bad thing seeing as informed discussion is how most progress is made (its just hard to find informed ppl)

In this hypothetical example, once PG has been ripped out (using the hole that is there) what is left could possibly be described as a gaping hole, if the attacker had left something behind that mimicked the tray icon then it might have taken longer to spot

 

I hope that DCS will carefully consider this potentially pivotal issue. I fully agree that PG shouldn't do the work of AV/AT/AS/FW et al. However, assuming it's installed on a clean system and isn't compromised while disabled, I think PG should do its best to ensure that it survives the inevitable reboot. Version 3.10 has greatly reduced the number of programs that can start before PG takes control, but until that hole is closed completely there may be room for improvement. One interesting design model might be Kerio PFW v2.1.x, which starts protecting before a user logs in. Also, by popping up a lightweight menu/dialogue as needed, the interface is always available at a critical moment. Adapting some similar elements might help PG win the startup race before it starts.

I'm assuming, Gavin, you are suggesting that the registry must be defended, and that if PG loses a startup race at reboot, the failure should be attributed to whatever program (or user) allowed an update to one of the many startup keys in the registry. I agree about needing a good registry guard, but still, "stuff happens". The registry is nearly as fragile as it is huge. Managing to protect a multitude of potentially sensitive keys/values against all possible attacks without blocking any necessary updates is daunting enough for advanced users, and light-years beyond what can be expected of an average user. Meanwhile, new attacks will arrive with regularity, and "stuff" will continue to happen. That's why it's so important for PG to try to win the startup race at all costs. After all, PG is the program that protects programs that protect programs. At the point where I'm looking for a program to protect PG, the irony may begin to overwhelm me.

ProcessGuard has shown an incredible ability to protect users from the many low-level vagaries of Microsoft Windows. I think everyone at DCS deserves a great deal of respect and credit for developing PG to its current state. I am hopeful that the generally perceived intent of ProcessGuard's mission can be preserved and persued into the future with an equal measure of dedication and success.