AppGuard Beta is Live (64 Bit, MemoryGuard)

Interestingly, I have added all the operating system components I had removed again: cmd.exe, regsvr32.exe and mshta.exe.

I added them all one by one, to see at which point a conflict occured. The conflict occured only when all of them had been added. At that point, I removed all except the two versions of cmd.exe. The issue disappeared, so I added both versions of regsvr32.exe, followed by both versions of mshta.exe. The issue is now not present.

Either the issue is somehow dependent on the order in which the applications were added to the guarded list or it is simply random.

I rebooted between every change made to the guarded applications list.

 

mshta.exe
Is this one recomended in the White Paper you mention?

 

I'm not sure if you've observed a bug or not. There's also the possibility that you made a common mistake that our GUI could frankly improve upon. When unchecking applications in the 'guard list', one must click on the 'apply' button. If you're confident that you did hit it, then we may have a bug that engineering needs to investigate. One should not have to reboot the PC. Perhaps, with the addition of MemoryGuard... I'll look into it.

Cheers,

Eirik

Oh and yes, please to send log files, msinfo files, observations, and feedback to our email. Thanks.

 

mshta.exe

I don't recall recommending that this be guarded. I'm unfamiliar with the potential risks this Windows binary poses. I'm not sure if Ace was able to do so without adverse consequences; consider me interested.

Cheers,

Eirik

 

Hello Eirik,

I hope I didn't miss it, but I don't think it's something AppGuard allows. You must be wondering what, uh?

Well, today I was working with some of my VMs (Virtual Machines), and I thought to my self: It would be great to have some application that would allow me to restrict what could be done to the system by Internet facing applications, for example, but to selective accounts.

I'll explain. Imagine the following.

I'm the Administrator. So, obviously, there is an Administrator account. Now, say there are two more accounts, which are least-privileged user accounts.
I login to the system using one of those least-privileged accounts. But, I'd like to make use of an Internet facing application, like browser or e-mail client, but using the other least-privileged user account.
So, I'd like to have the possibility only to apply AppGuard's restrictions to this secondary user account, and not to the all system, which is how I believe AppGuard works, for what I could verify a few months back. Maybe something has changed?

I also don't know if it would be possible to do it, but what do you think of, taking the example above, restricting thing even further, like say, allowing this secondary account only to make use of the Internet facing application (web browser, e-mail client, whatever...).?

Well, just though of sharing this crazy idea of mine. But, it would be nice though. Implementing something like this in some relative's and friends (and not only) systems would be great.

What do you think? Not that doable?

Thank you

 

Chalk another one up to user error. The issue is not random or dependent upon the order in which applications are added to the guarded apps list. I had forgotten to add a component the second time around that I had originally added to the guarded applications list: rundll32.exe.

I added the 32 bit rundll32.exe and clicked apply. No reboot was necessary and protection now seemed to be completely disabled. I could execute programs in user-space as well as view private documents from a guarded application as before. I removed the 32 bit rundll32.exe and protection now functioned as intended. I repeated the process with the 64 bit rundll32.exe and experienced the same problem. I unchecked all the other system components to further ensure that rundll32 was the problem. It was. Adding rundll32 by itself was sufficient to disable protection.

So, having either (or both) versions of rundll32.exe in the guarded applications list globally prevents AppGuard protection from operating correctly.

Mshta.exe is the Microsoft HTML application host. It is not recommended to be guarded in the white paper, which recommends rundll32, cmd and regsvr32 only. I currently use Comodo on another machine and have to add mshta to the rules there, as by default an application can execute an html application (.hta file) and thus escape the protection offered by comodo. More on HTAs here: http://msdn.microsoft.com/en-us/library/ms536496(VS.85).aspx#Security

It seems that adding mshta.exe to the guarded applications list results in much the same benefit as adding powershell.exe or cmd.exe to the guarded applications list does - prevents rare, but theoretically possible, attacks wherein a guarded application directly attempts to run a powershell script, batch file, or in this case an HTML application.

Now that I think about this more carefully, I don't see why powershell or cmd should be guarded. Doesn't AppGuard dynamically guard any application spawned from a guarded application? If this is the case, wouldn't powershell be guarded if, say, Firefox spawned it in order to execute a script or cmd be guarded if Firefox spawned it in order to execute a batch file? Or, does Firefox in this case utilize some facility of the OS to pass the desired script or batch file to the parser outside of the supervision of AppGuard, requiring that parser itself to be manually guarded? Or perhaps, is the execution of the parser allowed by default because it is not in user-space?

In any case, I'll make sure to send the results of this troubleshooting to your email. Would you prefer my observations here to be sent now or in a week, when I have the 7 days of log files and possibly other observations to send as well?

Greg:

If you want to take a look at the white paper, here is the link: http://www.blueridgenetworks.com/docs/AppGuard-Technology-Computer-Protection-White-Paper.pdf

 

I have a suggestion and a bug report for it:

1. Implement a hotkey that'll suspend/enable all protections.
2. Tray Launcher (http://code.google.com/p/traylauncher/) doesn't work properly when MemoryGuard is enabled (it gives an error box when trying to load a program via its shortcut menu).

 

It is doable but we implemented parental controls such that the same 'restricted' policies apply to all LUAs. Am I correct in inferring that you would like to apply different restrictions/policies to different LUAs? One might also infer that you might wish for another kind of policy. If so, would you please elaborate.

Cheers,

Eirik

 

I've passed this on to engineering to investigate. Thank you.

When a guarded application places and downloads a restricted script file from user-space, AppGuard prevents its execution. If a guarded application attempts to do so from system-space, the write operation is blocked.

Adding the script engines to the guard list applies the restrictions to ANY script regardless of location. Dynamically applying guard restrictions to a script engine so that scripts may launch from user-space can have unintended consequences. However, we are looking at it.

As pointed out, script based attacks are rare. And, we are positioning AppGuard as something of an anti-HIPS, if one accepts the premise that HIPS tend to be excessively complex for average PC users. The more we intervene with script engines the more we gray this positioning. We are looking at how to strike the ideal balance here. These observations of late regarding scripts is helpful. We hope you all continue to explore, speculate, question, and report observations. We are indeed making AppGuard even 'stronger'. Thanks to all.

Folks with simple environments are good for every week or so of log submissions. Those with multiple security applications and other complexities, however, would help us better, as well as themselves (log files can get big) by sending their log files in as often as they are comfortable. A stretch item for the next release would simplify this.

Cheers,

Eirik

 

Thanks, got your email also. This google thing particularly intrigues me. We'll do the hot key after we make some other changes first so we don't have to re-do the hot key.

Cheers,

Eirik

 

Ah, just now re-read this. What if you see both buttons of Enable and Disable? Let me guess, it's not Enabled..

Any update on the next Beta?

 

This shows -

MemoryGuard is disabled.
MBRGuard is enabled.

 

Oh my, Lol. I can't believe that I have stared at that and have read MemoryGuard to be MbrGuard. I am off to have my eyes checked. I wanted to post in my last reply that I could have sworn at one point that MbrGuard was enabled, LOL.

 

There won't be a new build for 2 weeks since Eirik is out of office.

 

Hi Guys,

I'm in the office. However, it is correct that the next beta will be around two weeks out. As you may have observed, with each beta we've introduced additional features. But, we've done so without significantly altering the GUI. In yesterday's status meeting on beta3, we concluded that the internal build between beta2 and beta3 is unacceptable. AppGuard has always been intended to be novice-friendly. This last build was not, and the beta2 as well. So, we decided we absolutely must make major GUI changes. I've asked engineering to schedule a series of design meetings next week. Meanwhile, I'm thinking about how we might leverage the valuable insight of Wilders folk.

BTW, MemoryGuard refinements appear to be on the mark based on log data we're continuing to receive from beta participants. Thank you!

I'm hopeful that this extra time means that we'll be able to make a few MBRguard tweaks as well. 64 bit users might note this is why we haven't signed the driver yet.

Cheers,

Eirik

 

Well, its been more than two weeks. Any news regarding the new version?

 

Barring a last minute internal bug find, we'll be releasing beta 3 Thursday morning, maybe Wednesday.

It will feature a refined MemoryGuard. However, it will not feature a significantly altered GUI. This was superseded by a 'surprise' from our 'XP MemoryGuard Team, which came up with a practical method for implementing MemoryGuard on Windows XP. So, beta 3 will feature MemoryGuard for WinXP SP2+. Just when I had given up hope on this, they came up with something. I'm looking forward to your feedback on how well it serves you.

With beta 3 we're starting to introduce the notion of different security assurance levels. Users will have the option of the usual anti-execute preference (maximum) for user-space or they may allow things to launch but auto-guarded with MemoryGuard (medium).

Cheers,

Eirik

 

Anxious to try on XP sp3.

 

So, will the new beta come out today or tomorrow?

 

I expect it'll be posted tomorrow morning (Thursday/Eastern Time). It just got released by our test department half an hour ago. It then has a few more steps to process before its available for download from our website.

Cheers,

Eirik

 

Should we add to 'Guarded Applications' other security tools, like firewalls, malware apps, av, etc., anything running resident/real-time?

I forgot, been reading the Help, so that would mean as long as they don't run in the System context, right?

THANKS

 

You shouldn't. It would probably cause major slowdown/errors if you did.

 

Ok, one other thing in the Help from what I read it looks better to keep programs in the system path like Program Files to run all apps from?

As example I use Alt.binz for Usenet but that's a standalone exe and I use to just run it inside My Documents, but I see now it's better I keep that now as C:\Program Files\Alt.Binz and Guard it with Privacy Mode Yes?


THANKS

 

That would be correct.

 

Ok thanks...

Hey I posted this regarding AppGuard;

https://www.wilderssecurity.com/showthread.php?t=282625

Tell me what you think, or anyone...


THANKS

P.S. Does anyone think running Comodo Firewall with AppGuard a bit overkill?