AppGuard 4.x 32/64 Bit - Releases

It turns out you was right. For what ever reason I was thinking that Tor Browser would be able to write to files within it's own folder guarded. I was thinking it just would not be allowed to create new files. I guess Tor changed something with the Tor Browser bundle. An exception has to be made for parent.lock in order for it to work now.

 

The reason why I asked is because HIPS will always tell you EXACTLY what type of suspicious behaviors they are monitoring, including which registry keys are protected. So perhaps Barb_C can give some more info. But the way I understand it at the moment, is that malware can´t write to all of the HKLM registry hive, and can´t modify files inside Windows directories. But will apps be able to function then?

 

Some will, some won't. That's the fun with alternative security software.

 

Just try it, and find out. Never know, you may like it.

 

AppGuard is interesting. The developers seem to have designed it to restrict applications against behavior that exploits would use (yes I know obviously), without breaking their functionality, and resulting in a far more pleasant user experience than that of typical classical HIPS. What strikes me as odd and maybe even a little unnerving, no doubt because I’m not used to it, is that I would expect more “breakage”, so to speak, with these restrictions. After all, it takes very little for a HIPS to cripple an application when a pop-up isn’t allowed or allowed in a timely manner. Not to draw comparisons, but I see this sort of thing in Linux AppArmor; in many cases if I don’t allow a certain read/write attempt, the application is often noticeably restricted from functioning the way it’s supposed to.

 

It's very easy to break this program.

All you need is an application that drops an executable in a random user-space location (temp folders in AppData with changing folders in between) in order to launch. We've encountered several applications which do this in the past (for example: private internet access). Since the location is random you can't make user-space exceptions; or you have to make them so broad it defeats user-space launch protection almost entirely. Another method would be to make the parent process a power application, again severely compromising the integrity of the entire security concept.

Then there are applications which crash or through up error windows if they can't write to a certain resource. Most problematic is the registry in this case because you can't make exceptions there. Then you have to leave them unguarded, so again the integrity of the security concept is brittle.

The concept works until you run into actual problems.

 

My final piece of advice to fanboys of any "revolutionary" third party security products - do yourself a favor and get Windows 7 Ultimate, which support Applocker configuration and enforcement. Use Applocker. It took me 5 min to set up and enforce Applocker. Then use a standard user account for your everyday computing. You will get a much much more secure computer for yourself, security from the kernel level. If you don't realize my advice now and still want to be a fanboy of any third party "revolutionary" product, that's fine. You'll learn it later. Remember, any security software, even antivirus software, can be disabled or uninstalled by malware. In the end, the battle between malware and anti-malware all comes down to process priority level. It's very very difficult to identify and take advantage of a kernel exploit, especially a x64 kernel.

Stupid MS, it should make Applocker available on all editions of Windows for free, if it really cares about security.

 

A developer of a program that drops an executable in a random userspace location may want to reconsider their coding practices. AG has worked well for me on my small 8 machine network. I have always been able to find a solution to any problem I have encountered. There's no one security solution, or application for everyone though. I actually have Windows 7X64 Ultimate so I do have the option of using App locker. Hell, i could even use both if I wanted to. I have found though for my needs I have less trouble using AG instead.

 

> Posting such a post in a product support thread
> Expect gatling gun

Good gawd super ultra screenshots. Now we need to load more data than needed to open this page. How wonderful...

@FleischmannTV
When you said "It's very easy to break this program" I thought you were talking about AG bypass. But I then realised that you actually are talking about AG may break certain programs' operations. Some software do indeed require above-average permissions for it just to run. But most threat-gate apps don't require those high-level permissions for daily usages, so IMO it shouldn't be a problem in most situations. Unless one wants to throw everything into AG's protection, but that's overkill IMO.

 

Yeah, I thought he was talking about breaking AG also until I read more of his post. It still kind of sounds like that is what he is saying. Maybe he should reword his post to prevent confusion.

 

Most users would not be able to configure AppLocker. It's not exactly user friendly for any novice user. I would even venture to say most intermediate users would have trouble with AppLocker depending on their learning curve.

 

AG is effective, easy for the average user to set up, inexpensive, and does what it was designed for very well. Is it perfect, NO, is any security perfect, NO, does it provide a very good layer of security for anyone who uses it, YES.

 

Fully agree, that can be a huge problem and results in the desired simplicity of AG. The issue was discussed in the past and so I hope in future there will be more fine tuned configuration options.

For the above it just needs that AppGuard supports some placeholders (* ; ? ) in folder names and execptions would work.

 

Yeah, Adobe Flash forces one into some creativity:

C:\USERS\*\APPDATA\ROAMING\ADOBE\FLASH PLAYER\NATIVECACHE\*\*\ADOBECP*.DLL
C:\Users\Admin1\AppData\Local\Temp\install_flashplayer*axau_mssd_aaa_aih.exe

...those are just a few of many I use. The wildcard "*" is needed because of so much randomness that occurs in those path locations.

 

It could possibly be that further up in the process hierarchy there is a Guarded Application. I would really like an upcoming version of AppGuard to include the entire process hierarchy when it blocks a message so that we would know for sure that it was due to a Guarded App being a grandparent or great grandparent. If you're using Windows 8.1, it is also possible that a recent bug we found could be the culprit. This bug has been there all along but only is an issue in 8.1 because of a change in a Microsoft API (but I believe that it is only in code that should be relevant to the Enterprise version). But will request more info from the development team to find out if this could be the case.

 

Thanks to all of the others that came to AppGuard's defense. I can assure you that our web site is not BS - all the claims are 100% accurate. We have people within our company that have been running without an AV for years without infection, but it is not something we're willing to recommend to others. We believe in defense in depth.

There is a good reason to continue using an AV to clean up dormant viruse files that might get onto your system. As we say on our web site, AppGuard does not detect viruses. We just detect suspicious behavior and stop the behavior. This may not stop some of the virus files from making their way onto your system, but we will either stop them from running, or contain them.

Anyway, if you don't feel the members of this forum have addressed all of your questions/concerns, please PM me (be patient, I' don't get on here as often as I'd like) and I will either answer them or put you in touch with someone at Blue Ridge that can.

 

Sorry, I really disagree with you about your statements regarding our web site and AppGuard. It is a revolutionary product. I don't know of any other company that can make the claim that to our knowledge, no malware would have bypassed AppGuard in its entire lifetime (at least 5 years). First of all it is not JUST an anti-executable. It allows most legitimate executables to run, but it contains them. It blocks sophisticated attacks such as CryptoLocker and Critroni - out of the box with no customization. And this was on the first day that those malwares came into existance. We did not have to quickly issue an update.

BTW, the prompting of the end-user when we do block an executable is a new addition in version 4.1 (and you can turn that off). Previous versions didn't really let the user know about this (unless they investigated the flashing icon). We did get dinged on this in PC Magazine's review so we added it (though our user-base really hadn't complained).

Anyway, I guess I'm pretty defensive about this product. It is effective and if you choose not to use it, it's your loss (at least in my opinion).

 

Really getting the impression that I can't win with respect to some other posters. BTW, I deleted that post that you responded to (you're quick) because someone posted a better answer (I think the query for the version isn't causing that, but the update logic, which I think I knew and may have even posted, BUT I've been sick so forgive me!).

 

Sorry (really) to see you go. AppGuard can stand up to the criticism. BTW, AppGuard 1.0 was released in January 2009. There was also a precursor to this product (I think we called it EdgeGuard Solo or TokenGuard - my memory isn't what it used to be). So it has been around for quite awhile and I think it is here to stay. It is also available from AOL as Tech Fortress with thousands of users!

 

Hi Rasheed! I don't want to list all of the registry keys that we protect, but we do not allow Guarded Applications to write to HKLM and several critical HKCU keys (and others). PM me and I can check with my management to see if they consider this proprietary information. If it is not considered proprietary, I will provide you a detailed list of keys.

"Protection against changes to system space" means that we don't allow Guarded Applications to write to system directories such as c:\Program Files, c:\Windows, C:\ and other directories outside of "user-space".

 

Generally the HKLM registry hive should only be written when something is installed or updated. Most programs do not need to modify it during normal operation - they modify HKCU. There are some exceptions though. Again, I want to check whether the list of registry keys that we protect is considered proprietary info. I'll update with a detailed list of keys if I am permitted.

 

Anybody else seeing this with the new Norton Beta?

 

FleishmannTV, specific examples please? Are you aware of the new wildcard options for specifying some of the policies. Perhaps these can help. Will you send specific examples to AppGuard@BlueRidge.com?