What is AppGuard

The best estimate I can give now is: before Labor Day (first Monday of September). Unfortunately, I cannot yet tell you if that will be a day, week, or several months earlier than Labor Day.

With so many sales channels for new Windows computers giving consumers no choice but to go 64-bit Windows 7, we're under growing pressure to deliver this support sooner rather than later.

As some of you may have heard from me, we're striving not to merely 'port' our framework over because there are substantial differences between the 32 bit and the 64 bit 'attack vector risks'. Our approach to security is prioritizing the risks so as to not unnecessarily complicate the end-user experience by mitigating low-priority risks. We've identified areas where we can make the most improvement to risk mitigation, areas we should not emphasize, and discrete R&D tasks required to complete our 64 bit support.

I know my answer is discouraging. If 64 bit AppGuard were the only priority, we could deliver it much sooner. It's because of other priorities and the likelihood of unplanned urgencies that we are not presently more definitive on a release date. Labor Day is my line in the sand. My intent is to release 64 bit support as far in advance of Labor Day as I can because the need is growing ever more rapidly every week.

Cheers,

Eirik

 

What is this and why has AG blocked it?

Code:

02/04/10 18:34:38 Prevented process <Internet Explorer> from writing to <e:\windows\rescache\rc0004\rescache.hit>.

 

Hi Eirik,

Many thanks for the comprehensive reply. I guess I'll just have to wait a little longer then before moving to 64-bit Windows 7.

Regards

 

Ultimately, determining what is normal for an application is best down by the developer of that application. That said, our belief is that it may be related to IE and MUI (Multilingual User Interface) where IE maybe trying to place fonts etc. (just like some print drivers trying to install or update printer related spool/directories).

Cheers,

Eirik

 

Very likely!

Cheers,

Eirik

 

thanks Eirik and the password protection too i guez?

 

How is Appguard different from Faronics anti executable?

Seems like they both do the same thing.

 

to me they are similar programs maybe i am wrong and wait when they implement pasword protection then it will be a full anti-executable

 

Faronics anti executable provides password protection.

 

yes i know i wan talking about appguard

 

Kinda curious, how does implementing password protection make AG a "full anti-executable"

 

i meant for protection of the program been alter then nothing will be allow in your system after password apply it is all denny so no one cant disable the protection making it hard to introduce new software to the system

 

So what you're saying is, MS would be the one to answer the question?

You and yours say "it may be related" and mine wants to ask, shouldn't you know? My point is, be it good or bad in one's opinion, the OS is constantly doing things in the background. Most would say that it's for the better that the OS is doing things constantly in the background but some will think not. Anyway, how is AppGuard to know what is to be blocked pertaining to normal OS background activity? From your reply of "it may be related", I'm guessing it doesn't know which leads to this question, how is one suppose to allow this background activity if you are of the group who think it's a needed thing? Do you see my point? Monitoring the event viewer or AppGuard's status tab is not going to help because the background activity happens at random times. Should folders like the one mentioned in last reply or below be added to the "Exception Folders"? If for example, the one listed below is added to the "Exception Folders" list, would the process Rundll32 be the only Guarded Application that could write to that folder exception or does this open the door for any of the guarded applications to write in the Exception Folder? Just for the record, I fall into the group that doesn't want most of the background activity and here's one reason why

Code:

02/05/10 22:22:17 Prevented process <Windows host process (Rundll32)> from writing to <e:\windows\logs\systemrestore\propertypage.0.etl>.

I have system restore turned off on all drives, I don't see a need for the OS to be writing to the above log


Edit: OK, here is a decent example of what I'm questioning above

Code:

02/06/10 16:40:31 Prevented process <Windows host process (Rundll32)> from writing to <e:\bootsqm.dat>.

My understanding of bootsqm.dat is that it needs to be written to after a chkdsk has been performed on reboot. It appears for me that if it doesn't write to that file, the next reboot will initiate the chkdsk again.

While I'm on roll, what and why is this

Code:

02/07/10 12:38:28 Prevented process <efl1.2_setup.exe> from launching from <f:\win7\win 7 apps\file folder lock>.

why is it saying that it prevented from launching? All that was done was right click, select properties.

And some others that have been mentioned previously. Every other boot up, the AG tray icon goes AWOL. What's up with that?
Also, right clicking the tray icon and selecting "Suspend All Protections" doesn't always work. If it doesn't work on the first try, protection has to be re-enabled then suspended again. Some time back, I thought this had to do with my HIPS not having learned the process but in Win 7 this is not the case.

 

Does Appguard work with Defensewall?

 

They're similar types of application, so you wouldn't gain anything by trying to run both of them and they'd probably conflict anyway for exactly that reason.

 

Hi All,

I didn't receive a notification email about these recent posts.

Eirik

 

I suspect I'd have to engage one of our engineers to fully answer your questions, and I've got some other things I really must finish today. So, I'm going to ask an engineer to help. I'll message you the email address I have for you. If incorrect, please let me know.

Cheers,

Eirik

 

Thanks Eirik, e addy is correct.

 

Here's another one,

Code:

02/09/10 16:45:35 Prevented process <mrtstub.exe> from launching from <f:\1a808ed104828f3785766e>.

I had to disable/re-enable/disable three separate times before this would successfully run. Contrary to what the pic shows, it did not successfully complete until the last one. AG blocked it inspite of having selected disable all protection.


Also, I have to ask, is this a gimmick?

Code:

02/09/10 17:49:17 Prevented process <Internet Explorer> from accessing to <e:\users\seven\documents>.

The above statement in the code box and with my understanding appear to be false. My proof, I posted the screenshot above didn't I? IE made access, retrieved, and uploaded the screenshot file. That looks like a touchdown for the opposing side to me, or maybe I'm mis-understanding this process/access jargon.

 

The crux of the question is whether or not a blocked activity by a guarded software application blocked a malicious or normal action by the software application.

An engineer replicated your observations on a single host without trying to perfectly replicate your environment. I relayed his assessment. Blue Ridge will not characterize an engineer’s observations of a statistically insignificant sampling of observations as an authoritative conclusion. The engineer did not conduct a comprehensive forensic analysis as that is too costly. Even this approach may require a statistically significant sampling to make an inference with a certain confidence interval. Even so, this leaves room for error. A far more deterministic means for answering a question such as this comes from analyzing source code. So, ultimately, the developers of an application are best positioned to distinguish normal from abnormal behavior of their application. In this case, no one is better positioned than Microsoft to make the determination. Blue Ridge is too small and has no interest in challenging such software vendors for that position.

Microsoft developed the Windows NT Security Framework years ago. AppGuard in effect enforces some of these practices. Even Microsoft developers do not always adhere to them. For awhile, about a year ago, MSN Messenger could not be guarded by AppGuard because an update to Messenger violated the framework. Blue Ridge did not tweak AppGuard to accommodate Messenger. Instead, we notified Microsoft developers. Months later, Microsoft corrected the framework violation. It consequently runs fine while guarded.

Forums such as these help bring these to our attention, so we can relay them to their respective vendors. In deference to privacy concerns, we did not implement a community-based reporting mechanism to amass reports and funnel them to vendors. We may revisit this with some kind of opt-in approach.

So, we don’t strive to definitively know normal from abnormal application behavior so much as we strive to relay such potential framework violations/observations to their respective developers.

Blue Ridge does not have such resources to provide. We recommend that AppGuard users post questions to the respective vendors: normal/abnormal (?).

The exceptions would apply to all guarded applications. In the future, we may facilitate per-application exceptions.

I may be misunderstanding the engineer. But this may be another example of why we’re looking at adding a new feature to AppGuard. It would enable suspended protection would last through a system restart. A more familiar use-case involves multi-stage patches/updates whereby part of the changes/modifications do not occur until after restart.

Generally speaking, most consumer users shouldn’t have problems with Rundll32.exe guarded. Power users and perhaps enterprise organizations, however, ought to be on the watch for unintended consequences.

Engineering needs to investigate this one further. We agree with your conclusion that there should be no block.

On the surface, this could be due to a software conflict with other security software. However, in Windows 7, this should be far less common than in Windows XP. You’re other security software in this host is? Real Time Defender? Shield Client Service? We'll need to dig into this further.

There’s another possibility of course, I’ve asked engineering for information on one of them.

 

As in your earlier post, there appears to be interference between the AppGuard GUI application and the AppGuard drive communications.

I assume the screenshot file was located in the directory that AppGuard says it prevented IE from accessing. Correct?

There's considerable evidence that you've provided indicating that AppGuard is not operating normally (e.g., protection not actually suspended after clicking accordingly). I'm afraid this suggests that your touchdown may be called back on account of offensive pass interference: something about your computer has AppGuard impaired. I don't know if it is the HIPS software on it or something else.

If you're interested, we'd be happy to look at your latest msinfo file and event log file.

 

Eirik, you have done well my friend! Thankyou for your time. As to Win 7 security, UAC, SRP and DEP. None of the others you mention. Those are in XP. I gave up on AG in XP

 

Lol, on the pass interference. I like that, BTW Roll Tide!
I mentioned in my last reply the security which is minimalistic to say the least. Oops, I left one out, Windows 7 Firewall Control Plus.
Answer to question, the screenshot file was located in the directory that AppGuard says it prevented IE from accessing. Thanks for your efforts.

 

I have a question, do I need to turn AppGuard off for Windows update to work correctly?

 

For the installation of updates, I've found this to be a yes