What is AppGuard

[Eirik]

Hi All,

We've been plugging away on this and that. Yesterday I discussed prospects for making available to Wilders posters one or two prototypes, when available, for feedback. I'd rather not comment on what they represent until we're closer to offering them, in case they don't work out.

Cheers,

Eirik

[Eirik]

Originally Posted by danny9

Hi Eirik,
AppGuard running and working well here.
A coiled snake ready to strike at anything that dares try to come down the pike.

I know it's been a little quiet here lately but continue to keep us informed of any new developments.

Getting a little wired from all the coffee I've been drinking waiting here.

Dan

Glad to hear AppGuard has your back.

At this moment, I am regretting the last cup of coffee that I drank. I'm feeling a bit too jittery. The French Roast sometimes does that.

Cheers,

Eirik

[Eirik]

Originally Posted by Blackcat

Same here; light as a feather and virtually no performance hit at all.

Compared to similar products, virtually no CPU usage and very little effect on CPU time.

And official support at Blue Ridge has been very good.

Cool screenshots. I hope you don't mind if I link to them from my website. I need to do a better job of emphasizing AppGuard efficiency.

Thanks for the Kudos on customer support. I'll pass that on.

Cheers,

Eirik

[Blackcat]

You are welcome to use the screenshots, Eirik. I find that my computer feels more zippy using AppGuard rather than some other policy sandboxes I have used. The practically zero CPU usage and the very low CPU time help to make AppGuard a featherweight as regards real-time performance.

I sent a email late on Sunday and received a detailed reply back first thing Monday morning so no complaints there!

[Eirik]

{Yes, another post in what 5 minutes. I told you that coffee made me jittery.}

I'd like to ask you all a question.

This week an AppGuard user, he frequents Wilders, shared an interesting AppGuard blocking log event pertaining to Firefox.

Prevented process <C:\Program Files\Mozilla Firefox Test\firefox.exe> from writing to <c:\system volume information\_restore{7c933bf5-7c65-49e7-9d15-e9ae5162143b}\rp3\a0000006.mfl>

I'm not aware of Mozilla leveraging 'system restore' resources in Windows. But, I've noticed that they sometimes do some unusual things. So, its not beyond the realm of possibilities that this is legitimate. Though, it could also be a malware incident because some malware routinely sabotages 'system restore'.

Question: does anyone know if Mozilla is intentionally trying to manipulate or utilize 'system restore' functionality?

Thanks,

Eirik

[pandlouk]

Originally Posted by Eirik

Perpetual license (use forever) that includes free updates for the first year. Subsequent annual updates are roughly 20% of that original price. If there should be interest, we might create a lifetime updates offering.

I am always interested in software with lifetime updates.

Panagiotis

[pandlouk]

Originally Posted by Eirik

{Yes, another post in what 5 minutes. I told you that coffee made me jittery.}

I'd like to ask you all a question.

This week an AppGuard user, he frequents Wilders, shared an interesting AppGuard blocking log event pertaining to Firefox.

Prevented process <C:\Program Files\Mozilla Firefox Test\firefox.exe> from writing to <c:\system volume information\_restore{7c933bf5-7c65-49e7-9d15-e9ae5162143b}\rp3\a0000006.mfl>

I'm not aware of Mozilla leveraging 'system restore' resources in Windows. But, I've noticed that they sometimes do some unusual things. So, its not beyond the realm of possibilities that this is legitimate. Though, it could also be a malware incident because some malware routinely sabotages 'system restore'.

Question: does anyone know if Mozilla is intentionally trying to manipulate or utilize 'system restore' functionality?

Thanks,

Eirik

Firefox itself never leverages system restore or vss (at least in XP).

Panagiotis

[Sully]

A quick test.

Start FF. Make sure options are to ask where to download. Download something. Save in user space, ok. Save in some other directory (c:\testdir) fails.

Go into FF directory. Copy FF and rename to something, like firewolf.exe. Start firewolf.exe. Download something. Save in user space. Try to save in some other directory (c:\testdir), succeeds. Bypass of path rule available.

User space is still protected. Just an interesting thing to mess with. The 'secret mechanism'?

Sul.

[Eirik]

Originally Posted by Sully

A quick test.

Start FF. Make sure options are to ask where to download. Download something. Save in user space, ok. Save in some other directory (c:\testdir) fails.

Go into FF directory. Copy FF and rename to something, like firewolf.exe. Start firewolf.exe. Download something. Save in user space. Try to save in some other directory (c:\testdir), succeeds. Bypass of path rule available.

User space is still protected. Just an interesting thing to mess with. The 'secret mechanism'?

Sul.

AppGuard suppresses all executable launches from user-space that are NOT guarded, regardless of what spawned them.

"Firewolf.exe" would run unrestricted if unguarded.

If Firefox (guarded) were hijacked to create "Firewolf.exe", Firefox would be unable to write the copy into the 'Program Files' directory. On the other hand, if the hijacked Firefox could spawn a "Firewolf.exe" (located on a drive other than the system drive), then AppGuard would dynamically 'guard' "Firewolf.exe" as it would any other spawned executable.

The 'other' drive issue will be addressed in the next AppGuard release with what I call "extended user-space". This will suppress "drive-by download attacks" that land on another drive, allowing 'guarded' apps to launch only.

I'm hopeful that we'll be able to include some kind of 'exclusion' capability so that folk can still use Sandboxie, for example.

Cheers,

Eirik

[Criss]

Originally Posted by Eirik

I'm hopeful that we'll be able to include some kind of 'exclusion' capability so that folk can still use Sandboxie, for example.

Cheers,

Eirik

This feature is really important for me.

[Eirik]

Originally Posted by Criss

This feature is really important for me.

I hear you. Thanks,

Eirik

[jmonge]

hi Eirik do you have any new version update/upgrade in mind?thanks and keep up the good work

[Eirik]

Originally Posted by jmonge

hi Eirik do you have any new version update/upgrade in mind?thanks and keep up the good work

No availability date for the next AppGuard release. We have to do a new release of EdgeGuard first. We're trying to include stretch items into this sprint that also benefit AppGuard and result in a fairly quick turnaround for an AppGuard release after the EdgeGuard release.

Cheers,

Eirik

[jmonge]

''great'',thanks

[Sully]

In the interest of understanding...

Originally Posted by Eirik

AppGuard suppresses all executable launches from user-space that are NOT guarded, regardless of what spawned them.

"Firewolf.exe" would run unrestricted if unguarded.

So, program files is not 'user space' for app guard? This is indicated because, if you have firewolf.exe (renamed firefox.exe), and start it, you can install applications to program files.

If Firefox (guarded) were hijacked to create "Firewolf.exe", Firefox would be unable to write the copy into the 'Program Files' directory. On the other hand, if the hijacked Firefox could spawn a "Firewolf.exe" (located on a drive other than the system drive), then AppGuard would dynamically 'guard' "Firewolf.exe" as it would any other spawned executable.

And here, you are stating that 'other' drives than the OS drive would not be considered 'user space'. But the 'guarding' by appgaurd dynmaically to for instance d:\test\firewolf.exe would allow .exe starting, but restrict it.

The 'other' drive issue will be addressed in the next AppGuard release with what I call "extended user-space". This will suppress "drive-by download attacks" that land on another drive, allowing 'guarded' apps to launch only.

So, the 'other' drive scenario, it works to 'guard' anything starting on an 'other' drive, but as such yet, there is not a restriction to starting an application on an 'other' drive yet. So the same .exe prevention that exists in 'user space: desktop' will be also extended in same fashion to 'other' drive? And is the drive(s) to be chosen by the user? Granular like? Hopefully.

So then, is this stating that:
Firewolf spawned from c:\my_test_dir will not be guarded at all?
Firewolf spawned from c:\program files will not be guarded at all?
Firewolf spawned from any other driver than OS drive will be guarded but not suppressed?
Future version - supression as well as guarding will occur if Firewolf spawned on driver other than OS driver?

Just where is total User Space defined for AppGuard?

Just to clarify

Sul.

[pandlouk]

Originally Posted by Sully

So then, is this stating that:
Firewolf spawned from c:\my_test_dir will not be guarded at all?
Firewolf spawned from c:\program files will not be guarded at all?
Firewolf spawned from any other driver than OS drive will be guarded but not suppressed?
Future version - supression as well as guarding will occur if Firewolf spawned on driver other than OS driver?

Just where is total User Space defined for AppGuard?

Just to clarify

Sul.

Sul,
a non admin or poweruser account cannot add/delete/modify files in sensitive directories like program files.

Panagiotis

[Eirik]

Originally Posted by Sully

program files is not 'user space' for app guard?

We define user-space as directory space where an end-user without admin rights has the privilege to perform write operations.

Documents and Settings/login_name

The important point to note about user-space in the context of AppGuard is that the 'drive-by download protection' feature suppresses all executable launches from within user-space unless explicitly guarded (on the 'guard' list).

Originally Posted by Sully

'other' drives than the OS drive would not be considered 'user space'. But the 'guarding' by appgaurd dynmaically to for instance d:\test\firewolf.exe would allow .exe starting, but restrict it.

Yes, Firewolf.exe would be permitted to launch. And, when Firewolf.exe is spawned by a guarded app, then Firewolf.exe would run but restricted.

AppGuard should consider other drives user-space (a.k.a., extended user-space) as well. Presently it does not. While this is fine for the majority of PCs, frankly a large and growing percentage of PCs have other internal drives, partitions, and external drives. A new AppGuard release will address the rest of the PC population that has an extended user-space.

This will mean that all executables would be suppressed from launching from other drives unless explicitly guarded.

Originally Posted by Sully

So, the 'other' drive scenario, it works to 'guard' anything starting on an 'other' drive

Not quite, AppGuard would only allow 'guarded' executables to run from the other drive. All others would be snuffed out, even if spawned by another 'guarded' app. This Draconian restriction is meant to prevent keyloggers and code injections from ever beginning. Again, only explicitly guarded executables may run from user-space because such apps are highly suspect due to the relative ease from which they can arrive there.

Originally Posted by Sully

So the same .exe prevention that exists in 'user space: desktop' will be also extended in same fashion to 'other' drive? And is the drive(s) to be chosen by the user? Granular like?

By default, all secondary drives would be considered (extended) user-space. However, we hope to provide some 'exclusion' capabilities for advanced users in a manner that does not freak out novice users. One of the drivers for this is to accomodate Sandboxie and other apps.

BTW, I'd appreciate even more feedback from folk on the likely uses of 'exclusion' capabilities so I can include them in our use-case perspectives.

Originally Posted by Sully

So then, is this stating that:
Firewolf spawned from c:\my_test_dir will not be guarded at all?

If Firewolf.exe were spawned by a guarded app, Firewolf.exe would be permitted to launch, because the location is outside user-space. But, it would be guarded because it was spawned by a guarded app. However, that guarded app would not have been allowed to create that "my_test_dir" because guarded apps are forbidden from writing to the root directory of the primary drive.

Originally Posted by Sully

So then, is this stating that:
Firewolf spawned from c:\program files will not be guarded at all?

If a 'guarded' app spawned it, it would be guarded dynamically. Again, the guarded app would be unable to place Firewolf in there in the first place.

If Firewolf were placed into the 'program files' directory by a user with admin rights, or an unguarded app with admin rights, then, if it were spawned by an unguarded app, it would run unrestricted. AppGuard does NOT automatically guard any executable that launches from 'program files'.

Originally Posted by Sully

So then, is this stating that:
Firewolf spawned from any other driver than OS drive will be guarded but not suppressed?

I believe you meant "drive" not "driver" above. Yes, presently (pre-extended user-space), AppGuard would allow Firewolf to launch from a secondary drive. If it were spawned by a guarded app, it would be guarded dynamically. If it were spawned by an unguarded app or launched by the user, it would not be. This illustrates the importance of extending our user-space definition to other drives.

Originally Posted by Sully

So then, is this stating that:
Future version - supression as well as guarding will occur if Firewolf spawned on driver other than OS driver?

Future version will suppress all unguarded executable launches. In other words, only guarded executables could launch from secondary drives.

Right now, users of both AppGuard and Sandboxie, must define the sandbox on a secondary drive. When AppGuard extends its user-space definition, Sandboxie would no longer operate as desired. I cannot remember the root of the conflict at this moment.

Nonetheless, we hope to provide advanced users some flexibility to define an 'exclusion' directory, which could be an entire drive, so that they can continue to enjoy Sandboxie. That would mean that the user relies on Sandboxie to regulate executables within the exclusion directory.

Well, I hope I've answered your questions clearly. If not, I'll be back to keep at it.

Cheers,

Eirik

[Criss]

Originally Posted by Eirik

Future version will suppress all unguarded executable launches. In other words, only guarded executables could launch from secondary drives.


Cheers,

Eirik

Hi Eirik,

I have a little query here. U said that only guarded executables are allowed to launch. So does this mean that i also need to put my anti-virus into the guarded list?? And if i play online games, do i also to put the executables of the game into the guarded list??

Sry a bit confuse here.


Criss.

[Sully]

You define user space as directory space where USERS have rights to create/modify. This is the only space then? Just want to be sure there are no extra directories that would normally under USER be not allowed create/modify.

Further, if AppGuard monitors user space dirs, what does it do with dirs like windows that allow a USER execute/read access? Anything? I ask because, if I am admin, and have appguard running, and spawn .exe on desktop, supression occurs. If I am admin, and spawn cmd.exe, cmd.exe is not 'guarded'? Which in turn leads to cmd.exe being able to effect what? Sysdir? Program Files?

I know what the difference is between a admins rights and users rights. What I don't understand is exactly how AppGuard handles the distinction between them. In many security apps, they are designed to treat the user as a user, even if they are actually admin. AppGuard seems to be treating the user space only in such a way. True that if you have a guarded app in the list, it becomes a user for all intents and purposes. So then, is appguard only monitoring when a program is added to the guard list, unless it exists in user space.

I understand what it does, just trying to get a feel for what it included or excluded.

Thanks for taking the time to reply.

Sul.

[Eirik]

Originally Posted by Criss

Hi Eirik,

I have a little query here. U said that only guarded executables are allowed to launch. So does this mean that i also need to put my anti-virus into the guarded list?? And if i play online games, do i also to put the executables of the game into the guarded list??

Executables that are located within user-space can only launch if they are explicitly guarded. Anti-Virus software usually is not located in user-space. Simple games may be if installed by a user, particularly one without admin rights. As a rule of thumb, when in doubt, let it be blocked before adding it to the guard list. That will tell you explicitly that it is located in user-space and must be guarded to launch.

One last thought on AV, an AV has legitimate needs to write to almost anywhere.

Cheers,

Eirik

[Eirik]

Originally Posted by Sully

You define user space as directory space where USERS have rights to create/modify. This is the only space then? Just want to be sure there are no extra directories that would normally under USER be not allowed create/modify.

Just 'Documents and Settings/login_name'. If there's anything else, then I don't know about it. I'll ask engineering.

Originally Posted by Sully

Further, if AppGuard monitors user space dirs, what does it do with dirs like windows that allow a USER execute/read access? Anything? I ask because, if I am admin, and have appguard running, and spawn .exe on desktop, supression occurs.

AppGuard does not suppress launches in such directories as Windows. This is probably due to the fact that admin rights are required to conduct write operations. Remember, I didn't engineer AppGuard. I only play one on TV.

Originally Posted by Sully

If I am admin, and spawn cmd.exe, cmd.exe is not 'guarded'? Which in turn leads to cmd.exe being able to effect what? Sysdir? Program Files?

I believe one may guard "cmd.exe". I believe this was not placed on the guard list by default was to avoid conflicts with enterprise batch files and for concern over unintended consequences. I'd like to encourage adventurous folk to guard "cmd.exe" and let us know if doing so interferes with legitimate actions. (Again, we know that this can hinder enterprise batch scripts)

Originally Posted by Sully

So then, is appguard only monitoring when a program is added to the guard list, unless it exists in user space.

I don't know how extensively it looks at unguarded executables outside of user-space. I do know that it does not interfere with them.

Well, I wrote this post before having my morning coffee. I'm ready to go back to bed. Must super caffeinate!

Cheers,

Eirik

[Criss]

Originally Posted by Eirik

Future version will suppress all unguarded executable launches. In other words, only guarded executables could launch from secondary drives.

Right now, users of both AppGuard and Sandboxie, must define the sandbox on a secondary drive. When AppGuard extends its user-space definition, Sandboxie would no longer operate as desired. I cannot remember the root of the conflict at this moment.

Nonetheless, we hope to provide advanced users some flexibility to define an 'exclusion' directory, which could be an entire drive, so that they can continue to enjoy Sandboxie. That would mean that the user relies on Sandboxie to regulate executables within the exclusion directory.

Well, I hope I've answered your questions clearly. If not, I'll be back to keep at it.

Cheers,

Eirik

Opp, Eirik i just found out that i misread what you wrote above.

Thank for reply anyways.

[Eirik]

Originally Posted by Criss

Opp, Eirik i just found out that i misread what you wrote above

No worries. The nuances of this stuff can be very confusing. And, its difficult to succinctly and clearly write about this stuff.

[jmonge]

Originally Posted by Eirik

No worries. The nuances of this stuff can be very confusing. And, its difficult to succinctly and clearly write about this stuff.

will you add all types of executables?or just few?thanks

[Sully]

The more I play with this, the more it reminds me of a hybridized SRP approach, with a few twists.

I would pose the question to myself, if I run in admin mode, which I do, what are the differences? For me, I use SRP with Basic User. I restrict certain directores to user and specific applications to user. What child processes these spawn inherit the user rights. I am unsure if this is token passing or not with SRP. Anyway, when using SRP, the items protected are ok then.

So I have had an interest in AppGuard because of the User Space guarding that it does. I am not sure adding a guarded application is really any different from SRP in much. It does offer an easy 5 minute disable feature which is convenient. I have tried it in conjuction with SRP and it would appear from the msgboxes that AppGuard is intercepting before SRP. Full knowledge of AppGuard though is needed for me in this case because I am trying to see which would overlap which and at what point. For those who use SRP to restrict all but admins, I have not played with that scenario.

So far I have not seen any detrimental effects. Indeed, almost as if it seems that if AppGuard would somehow fail to guard an item in it's list, SRP should pick it up.

I am wondering if you can find out, are the triggers different for AppGuard vs. SRP? Can one use both, and find true that AppGuard would fire on some function that is fired before the function that triggers SRP? This would seem to be a lovely combination in as much as both are pretty silent, both do very similar things. But inclusion of AppGuard add some benefits not available for SRP.

You know, you have to play with strange combinations to sometimes see what will happen that you did not expect.

For instance there is a PoC attack against DMR and SRP. Would AppGuard be immune because of it not using token adjustments?

Sul.