AppGuard 4.x 32/64 Bit - Releases

Did updating "The Bat" fix the problem? I'm having difficulty following what is going on here. As I understand it, "The Bat" was writing to HKLM when it was starting up (was this an old version and now TB doesn't do that?). If that is the case, AppGuard is behaving as designed and I don't think there is anything in AppGuard that needs to be fixed. We have debates internally about allowing users to add registry exceptions, but our lead Software Engineer is pretty adamant about not adding that "feature" because it would open up security holes and complicate the product even further.

 

Using the old version but allowing launch from user space.

As to adding registry exceptions I would say that it should be allowed but with notification.
There can always be a checkbox in preferences which doesnt allow any registry exceptions to gain the security you software engineer desires.

All security is a compromise between convenience and safety.
The only way i could get it to work was to add it to the power apps which would of been more of security hole than having one registry exception.

Most people would of just did what i tried and added it to power apps and not discussed it on here.

Martin

 

Barb, digitally signed apps (not under Trusted Publishers) are executed with limited rights under Medium setting.
That often causes them to crash or fail to install/update properly.
Users might get confused so maybe a notification popup that the file is executed as Guarded would come in handy.

 

That's an interesting observation. It would appear that if that registry setting isn't present, then The Bat uses some default settings for that key - otherwise why would it continuing without it being present? I'm curious if you leave that registry setting in and run TB, does the key get modified (of course turn off AppGuard during this experiment)?

Often due to lazy programming (I was guilty of this too when I used to write code), a programmer will request write access when only read access is required. In this case most of the time AppGuard avoids interfering with the application by allowing read access to go through for write access requests, but we prevent any actual writes.

In The Bat's case, it would seem that our "fake out" tactic is not working since The Bat is not working.

Another possibility (especially since posters have reported that a later version of The Bat does work with AppGuard), perhaps The Bat wasn't handling an error condition when trying to write to the registry causing the program to crash and they've fixed this in a later release (I'm not denying that AppGuard's protection may have induced the error condition though, but it shouldn't cause a program to crash). Since removing the key helped The Bat continue on it's way, perhaps it checks for the existence of the key and takes a different code path based on the result. Anyway, this is all speculation on my part and I'm glad that AppGuard and The Bat's latest version can co-exist.

 

Thanks for the clarification. I've thought of adding a "toaster" message indicating that "AppGuard is now Guarding Program X". This may become too noisy unless we just limit the message to the parent application, but then that gets into more complex programming.

 

The level/number of notifications could be a preference setting.

I prefer my security to be chatty/inform but i understand others want it to be near silent.
Having some level of feedback that isnt just a flashing system tray icon would reassure the user that the program is working correctly.

 

Yes, I also think that only running of a parent process should be notified.

 

Thanks for the input. You should come to Blue Ridge and take part in our discussions (maybe I could prevail for once).

I gather the program was Guarded because it was located in user-space? If that is the case, there are other ways to make it work (exclude the program from user-space protection or add a trusted publisher). In that case, the program won't be Guarded. I think for now you are taking the safest course - launching unGuarded and then Guarding.

In any case, trying to tweak our policy for a user-space application requires more knowledge of our program than most people want to take the time to learn. Hopefully we can come up with a clever way to make things more intuitive in the future.

 

Martin, Thanks for registering AppGuard! You can also email AppGuard@BlueRidge.com for support questions. This forum is very knowledgeable but it doesn't hurt to send us an email - especially if there are any licensing issues (even if I see them here, I'm no longer handling those requests).

 

You're welcome, Martin. I'm glad we found an acceptable workaround.

Kind regards
pegr

 

Hi Barb,

When I tested versions v1.62 and v6.2.14 of The Bat! to see if I could help trott3r find a solution, Sysinternals Process Monitor was showing that both versions appeared to be writing to HKLM on startup. I wondered if the difference in behaviour (v6.2.14 starts, v1.62 doesn't) was due to a coding difference in the way registry write errors are handled between old and later versions.

One thing I didn't understand is that Process Monitor was reporting the registry writes to HKLM by The Bat! as successful, but I couldn't see how that was possible as The Bat! was running guarded. Are you able to explain that?

I agree with your lead engineer that allowing registry exceptions would not be a good idea for the reasons stated.

Kind regards
pegr

 

I doubt that the registry writes were successful. I know that we do some kind of "fake out" to make the App think it was successful when in fact it was not so perhaps Process Monitor is also fooled by our "trickery". I'll ask the lead developer if he has a better explanation.

 

When The Bat 1.62 tries to write to HKLM\SOFTWARE\Clients\Mail\The Bat! you should see an ACCESS_DENIED result in Process Monitor.
Basically what happens is that at every launch, TB tries to obtain a handle to HKLM\SOFTWARE\Clients\Mail\The Bat! with KEY_ALL_ACCESS rights. Then it tries unnecessarily to write the same information that is already present in the registry for various values.
AppGuard strips the access token of write attributes, so The Bat receives an access denied error when trying to set these values.
From there, TB logs the access denied error and then graciously exits.

 

Thanks for the clarification! I'm sorry about my incorrect assumption that the program crashed.

 

Barb, how far are we from 4.1?

 

Heh i read what you said about process monitor again and read it as process explorer from sysinternals.

Is process monitor easy to use or does it produce a lot of output that needs interpreting?

 

It produces a lot of output that needs interpreting. That said, it is quite easy to use.

 

Thanks for the reply. I thought Process Monitor reported that the registry writes to HKLM were successful, but I could be mistaken. I'll try it again when I get time and check the results, but it won't be for a couple of days.

 

Ok thanks for that.

 

Hello Barb_C and anyone else interested in this issue: Over the last couple days I been having trouble with signature updates for Nod 32 av. I get an error message that says Nod had a problem creating a temp file for the update. When I move the Apgguard protection level settings to "install" I am able to manually complete a Nod 32 signature update.

From the AppGuard activity report-
03/16/14 14:37:26 Prevented process <ESET Service> from writing to <c:\windows\temp\nup7a2d.tmp>.
03/16/14 14:37:26 Prevented <ESET Service> from writing to <\registry\machine\software\eset\eset security\currentversion\plugins\01000400\settings>.

I didn't have Nod as a guarded or power app but after my manual update was successful I added Eset digital signature to Publishers with the following settings:
Guarded Yes, Privacy On, Memory On, Install Allow.

Should I keep Eset as Guarded? Any other changes I should make?

 

I would set Eset under Publishers at least with Guarded: No and Install: allow, possibly Memory: Off and Privacy: off as well. Further, I wouldn't list any Eset processes under Guarded Apps.

 

+1.

 

Personally, I would be inclined to add ESET to the Publishers list using the same settings as the Blue Ridge Networks entry, which is there by default. If BRN thought it a good idea to add themself then it's probably a good idea to do the same for any security application that needs unrestricted access to the system.

 

You would not want to use Privacy, or Memory protection with NOD 32. The memory protection could interfere with NOD 32's ability to detect threats running in the memory, and Privacy Protection would prevent NOD 32 from scanning files in any folders you have designated as private. You should use the same settings that are defined for Blue Ridge Networks as already mentioned by Pegr.

Also, I had to make the following components of NOD 32 power apps as shown in the screen shot below. I did this because AG was actually blocking some actions from those components of NOD 32.