AppGuard 4.x 32/64 Bit - Releases

It is a memory guard event and exceptions for memory guard can no longer be made. The exception you tried to make, shadek, was giving write permission to a protected folder.

 

Loving 4.1 beta. Just one question did the folder options changed under guarded apps? I don't remember it having protected, private and exception.

 

Thanks! Much appreciated!

 

Purely for learning purposes, try making conhost.exe a power application and see if that allows it to write to the memory of nplastpass.exe. It wouldn't be advisable to leave conhost.exe running as a power application permanently though, even it achieves the desired outcome regarding LastPass. This suggestion is only intended as an experiment, nothing more.

 

http://www.appguardus.com/support/products/appguard/files/

am I looking in the correct folder for the 4.1 build ?

 

Yes. It does work, but since it breakes such a big hole in the attack surface, I chose not to make it Power App. I was wondering if it there was some other way, but there isn't one. Anyway, hopefully everything will continue to run smooth.

Thank you for your input!

 

@ Windows_Security

I think I may be misunderstanding the "Memory Guard" feature. What if some legit app wants to inject code into the browser (or Guarded App), will that always be blocked? And what if it causes that app to malfunction? Also, direct memory access (used by rootkits) is a whole different thing, you´re really confusing me.

 

You need to contact BRN if you want to beta test. They will provide you with the proper download link.

 

Not in this release. Sorry.

 

Allowing Guarded Applications to write to nplastpass.exe will only allow it to write to the actual file itself. So making nlastpass.exe an exception file does not effect MemoryGuard protection. Basically what we need is a mechanism to allow MG exceptions for Guarded Applications. A lot of you are probably thinking that we already had that feature in 3.5 (at least we had something called MG exceptions previously), but that was providing unGuarded applications the ability to write to a Guarded Application's memory (not vice versa). With version 4.0, we removed the need for that feature, because if an application is not being Guarded we don't block it from accessing the memory of other Applications (even Guarded Applications).

So why is AppGuard blocking conhost.exe from writing the memory of another application if it isn't Guarded? I suspect that a Guarded Application is somehow in the mix (a parent or grandparent perhaps). Unfortunately, the AppGuard message info for Memory Guard events doesn't always provide info about the "parent process" (and even if it does, it won't indicate the grandparent processes which may indeed be on the Guard list). I'm doing some research to try to understand how conhost.exe works and under what circumstances we might block it. Also, my husband uses LastPass on our home computer and I will play around with it tonight to see if I can repeat the issue and shed some light. What OS are you using? I'm on 64 bit Win 7.

I'm glad that you're not seeing any issues and I think the only solution would be to either turn off MG Write protection (not advised) or to ignore the message.

 

I agree you shouldn't make conhost.exe a power app. As I said, it was an experiment purely for learning purposes. The fact that it worked though suggests that conhost.exe is running guarded even though it is located in system space. I suspect the reason may be that it is associated with another process that is running guarded, possibly cmd.exe.

Here is something else to try, again purely as an experiment for learning purposes. Temporarily uncheck the Windows Command Processor entry in the Guarded Apps tab and see if conhost.exe can write to the memory of nplastpass.exe without making conhost.exe a power app. If that works, you will have learnt something else. In any case, you should enable the Window Command Processor entry again in the Guarded Apps tab when you've finished experimenting.

 

If the legit app is not Guarded, AppGuard will not block it from injecting code into a Guarded browser (or any other Guarded Application). Previous versions of AG did block this activity and we provided the ability to set MG Exceptions to facilitate the legit apps, but that concept was too difficult for non-technical users to grasp. So, in version 4.0, we decided to only Guard the Guarded Applications (which really makes sense and simplified AppGuard's policy significantly while still providing significant protection). So in other words, an application that is Guarded cannot access memory of other applications (even other Guarded applications), but other applications can access the memory of Guarded applications. Furthermore children (and grandchildren) of Guarded applications are Guarded via our patented policy inheritance. Also, any user-space applications are automatically Guarded if they are permitted to launch (in Medium level digitally signed applications in user-space are allowed to launch).

 

Bear in mind that I have the binary version of LastPass installed as well (not just the browser extension). When I started to use binary version of LastPass, that's when AppGuard started to block actions by LastPass.

Windows 8.1 x64 bit

 

Yes and I don't think it is being well received. What makes more sense to the non-technical user:

Private or Deny?
Exception or Read/Write?
Protected or Read Only?

The opinion around Blue Ridge was that the previous terms were too technical and that the new terms would be more acceptable to the non-techie. But since the 4.1 release, we've heard otherwise. So I'm asking for more opinions in this area.

 

The 4.1 build is available for beta testers. If you're interested in becoming a beta tester, please email AppGuard@BlueRidge.com. Please include your full name and country in the email. BTW, I'll be closing the beta enrollment soon.

 

Even the previous MG Exceptions feature would not have covered this case. It was only to allow non-Guarded applications the ability to access the memory of Guarded Applications. I believe that providing this type of MG exception (needed by Shadek, where a Guarded Application is able to access the memory of another process) would be supportable by our underlying framework, but this is the first instance that we've been made aware of an issue and in this case it doesn't seem to affect operation. If we see more issues in the future (and perhaps we will with Windows 8.1), we'll add the hooks at the application layer to add this type of MG Exception.

 

I think my husband has the binary version as well (but thanks for the heads up).

 

Thanks for suggesting that. That's one of the things that I was going to try tonight. You saved me a step.

 

v4.0 question: What's the difference between putting a folder into User Space
with the Include option set to 'No' and into the Guarded Apps exceptions
section with the Read/Write option?

 

Deny
Read/Write
Read Only are names non-technical users already see in windows itself,so I assume they're more familiar with those meanings....

 

I think the following below will be the easiest for everyone to understand. I like this better myself. Would this be too wide for the drop down box? You would have to make the Window larger in order for the following below to fit under the type field. You could also just use this as the description at the top instead of placing this in the drop down box.

Private (Deny: read/write)
Exception (Allow: read/write)
Protected (Read Only)

 

I suggest . . .

Locked (Deny: read/write)
Unlocked (Allow: read/write)
Read Only (Read Only)

 

I like the Private/Exception/Protected as long as it can be explained somewhere. Similar to what cutting-edgetech as proposed.

 

Hopefully, this will explain it: AppGuard 4.x 32/64 Bit

Also, see post #5 on page 1 of this thread.

 

Deny, Read/Write, Read was better in my opinion. Without the tooltip I wouldn't have understand the new terms either