AppGuard 3.x 32/64 Bit

I'm having a similar issue now! I have set Dropbox folder to be "Private".

I set Dropbox' application Privacy to Off under Guarded Apps. I reboot computer and the GUI then shows Dropbox' Privacy mode is On.... but in reality it is Off as I set it to be. A GUI bug?

If I set it to On for Dropbox and reboot it functions properly and block access to Dropbox target folder...

So something is definitely fishy about the new Privacy Mode.

P.S. I'm always in Lockdown Mode.

 

In the latest Windows Update round, 2 updates for the .net framework were blocked, but except that I've had no problems installing windows updates with AG on High.

 

Good, because this is something I was worried about. I'm glad Windows Update works with AppGuard on high

 

Updates works fine in 95% of the cases in Lockdown-mode as well!

 

I'll ask them to try with Windows 8 in the lab. Thanks for the input.

 

I can now confirm that new version, after reboot, puts all Guarded apps into Privacy = Yes. If I set them to No they will go back to Yes after reboot.

Windows 8 x64 with latest version of AppGuard in Lockdown-mode.

 

That's odd. There shouldn't be any difference in the Power Apps. I'll report this to our QA department to see what might be going on. Will you open a ticket via email (AppGuard@BlueRidge.com). Send a copy of your policy as well as a copy of the blocking events. The policy can be found at:

On XP:

C:\Documents and Settings\<user_name>\Application Data\Blue Ridge Networks\AppGuard\AppGuardPolicy.xml
C:\Documents and Settings\All Users\Application Data\Blue Ridge Networks\AppGuard\AppGuardPolicy.xml
​

On VISTA or Windows 7:

C:\users\<user_name>\AppData\Roaming\ Blue Ridge Networks\AppGuard\AppGuardPolicy.xml
C:\Program Data\Blue Ridge Networks\AppGuard\AppGuardPolicy.xml.
​

To generate an AppGuard Windows Event Log file:

• Control Panel

• Administrative Tools (may need to be logged in as admin?)

​

• Click on 'Event Viewer'

​

• Click on to highlight “Application” in left-hand pane, then

​

• Event Viewer menu “Action”, select “Save Log File As”

​

• Name it, change type to .csv

​

• Save and email it

​

 

We originally did that, but there was an issue - can't remember exactly what it was. I think it had to do with ultimately uninstalling the product entirely. If MBRGuard was not installed originally and then later turned on then MBRGUard would not uninstall if you decided to uninstall AppGuard altogether (but who in their right mind would do that?). Anyway, at the time we were probably trying to get a release delivered and took the quickest path to do that. Since no one has complained (until now), we haven't gotten back to "fixing" it.

 

Oh, please don't disregard this post - you said a lot of nice things too!

Thanks for the feedback! I believe that the GUI improvements were made because of your suggestions so thanks for that as well. It was an easy change to make and we were glad to do it.

As far as testing, I would appreciate any testing with the new wildcard feature. We do know for instance that it does not work when we tested with some Microsoft products (oops, not sure that I included that in the release notes - need to do that). In particular we could not do a file-save from IE or Word to one of the wild-carded exception folders.

 

It does look like we have some upgrade issues with this version. We'll see what we can do to improve this before the release.

 

When running in High protection level, you should not have an issue with windows updates. Even in Locked Down, most updates go through without a problem.

 

I'm not quite sure what you mean that Privacy Mode is ignored and always honored at the same time. Are you saying that the GUI is indicating that PM is turned On for an application when it really isn't being enforced for the application?

I believe that AppGuard is somehow resetting the Privacy Mode setting for all Applications (at least on the GUI) when the suspension timeout has elapsed. This may be triggered when the PM setting is changed on the Guarded Apps GUI or suspended from the menu. It seems that changing the protection to Off and then back on again will correct the GUI problem. Anyway, I will try to get more definitive steps to replicating this issue so that I can turn it over to one of the developers for a fix. Definitely an issue here!

Good Catch everyone that reported this issue!

 

LOL.. Of Course I only meant the bug report portion of the post

yeah, I was the one that requested a larger customize window. The UI looks so.... much better now!!

 

I hope they don't mistakenly disregard my second bug report I sent. I sent another report because AG failing to preserve my Trusted Publisher's List during the upgrade. I sent them an email telling them to disregard the report I sent about the AG installer not being able to create a restore point. That's the one I wanted them to disregard. The second report I sent about AG not preserving my Trusted Publishers List during the upgrade is still valid.

 

What I've noticed is that Privacy Mode does now work as configured in Locked Down Mode as I requested (thank you Barb) but the Guarded Apps tab sometimes incorrectly shows it as On for all guarded applications when in Locked Down Mode, even though it's not. It's just a minor GUI display issue because Privacy Mode is still working as configured. When the protection level is lowered, the individual Privacy Mode settings are again displayed correctly.

Regarding Privacy Mode re-enabling itself after being suspended for an application from the menu when the suspension timeout has elapsed, that has always been the behaviour but I've never been sure whether it's intentional, or whether it's a bug. Personally I would rather that suspending Privacy Mode from the menu operated independently of the suspension timeout.

 

The Guarded Apps Tab does not show the current status of Privacy Mode at all that i'm aware of. It only shows whether or not a guarded App is configured to run in privacy mode. It either says OFF, or ON in the Privacy Column next to it. That is just showing the configuration settings, and does not indicate the current status of whether or not that application is running in privacy mode. Are you talking about the first UI Window where it says Privacy Mode underneath Guarded Execution? I have it highlighted below with a red rectangle. Are you saying while running in lock-down mode sometimes it says as configured, and other times it says All? So sometimes while in lock-down mode it incorrectly says that all applications are being ran in privacy mode when in fact it should say, "as configured".

 

I just read your post again, and now I think I understand what you are saying. So sometimes under the Guarded Apps tab it says "On" for all Apps under the Privacy Mode column. In reality some of the Apps showing "On" for privacy Mode should say "Off" because they have been configured not to run in Privacy Mode. Is this correct or was I correct in the post just before this one? Well, I hope one of my post is correct anyways.

 

Contrary to my previous post, I just wanted to report that Privacy Mode is indeed working correctly, apart from the GUI glitch. I had the misconception that setting a 'Protected Folder: Read Only' would mean that a guarded app could write to it, provided that Privacy Mode was off or suspended for that app.

 

Yes, yes, yes! I'm glad you all can confirm my issue!! Barb, it seems it's not only Win 8 related!

 

Yes, this post is the correct interpretation of what I was saying.

I suspect what may have happened is that the GUI display issue is a consequence of the way it used to work in the previous version where AppGuard did put all guarded applications into Privacy Mode when in Locked Down Mode, irrespective of their individual Privacy Mode configurations, so it would have been correct in the previous version for the Guarded Apps tab to display it that way in Locked Down Mode.

 

Done, thanks for your help. Anyway I'm enthusiastic of AppGuard, very nice security software.

 

I just completed submitting the following bug report below. I have one more left to submit. I will post the details on the other one after I have submit it.

1. Create a folder in the userspace or on any volume other than C.

2. Use the Russian Cyrillic Alphabet to name the folder. (to make it easy for you just use these Russian characters to name the folder with "пдзз").

3. Go to the Guarded Apps Tab.

4. Then choose Designate additional protected folders, exception folder, or Private folders.

5. Click the settings button.

6. Navigate to the folder you just created.

7. Choose the folder, and add it to the list.

8. Configure the folder as "Deny Access".

9. Now try downloading a file with your web browser, and then save it in that folder.

The file will save in that folder with no problems. The file should have not been permitted to save to that folder. Access should have been denied to that folder. The Russian Characters are allowing Appguard's protection to be bypassed. This is not good at all if you are Russian since your folders will most likely be named with the Russian Cyrillic Alphabet. Actually there are about a dozen languages I can think of off the top of my head that use the Cyrillic Alphabet.

Ok, now follow the same steps above, but add a folder that has been named with the English Alphabet. Configure it to "Deny Access". Then attempt to download a file with your web browser, and save it to that folder. It will block all access to that folder from the web browser. It is my understanding that this is expected behavior.

It looks like Appguard is not able to protect folders, and maybe even files with the Cyrillic Alphabet.

Regards,

Mike

 

@Cutting Edge

I believe that this is a known issue regarding Cyrillic and diacritics.
refer to https://www.wilderssecurity.com/showthread.php?p=2206576&highlight=folder#post2206576

 

It is not that a big issue for me, but more important is if it keeps files with non-english characters from executing or not? Otherwise an attacker could just rename the file and bypass AG.

 

I tried renaming a non signed .exe file with Cyrillic Characters, and executing it by just double clicking it from an external drive. It would not execute, but that really does not prove much. The question is whether or not a threat with Cyrillic characters would execute through the browser, or other exploitable application.