We are close to releasing the new version of ExploitShield Browser Edition. It includes a lot of engine improvements such as memory protections for earlier stage exploit detection as well as deeper integration into the OS.

In order to release a more quality product we are looking for alpha testers to give it a test drive and provide feedback. If you would like to participate please PM me with an email address to send the details to.

We are close to releasing the new version of ExploitShield Browser Edition. It includes a lot of engine improvements such as memory protections for earlier stage exploit detection as well as deeper integration into the OS.

In order to release a more quality product we are looking for alpha testers to give it a test drive and provide feedback. If you would like to participate please PM me.

Sorry, I've tried on Windows 7 and Windows 8 computers.
ExploitShield does not work with Sandboxie.

Click to expand...

64-bit...? Then you also (or, instead) need to OpenIpcPath for $:ExploitShield64.exe as well (I never went back and updated my compatibility posts here and on the SBIE forums after realizing that). Assuming nothing else has changed since ES 0.7, that needs additional/different settings... (I haven't used a newer version yet.)

m00nbl00d said:

I still don't know why would Sandboxie users want to allow these IPCs? It only opens holes in the sandboxes, and it defeats the purpose of Sandboxie.

Click to expand...

That's absurd! The "holes" are for compatibility, and most [of the built-in compatibility settings] shouldn't have any effect on "defeating" the purpose of Sandboxie. KNOW what the effect of stuff you're opening up is, and you can safely open up a lot. Or leave it alone if you don't. Do you have an idea how much stuff Sandboxie opens up ("allows") by default because it has to? So, no complaints about those from you...? Sandboxie itself defeating its own purpose?

In NO way would these settings have ANY effect on the security of Sandboxie. Unless there's bugs in ExploitShield that you are then allowing access to. In that case, one should not be using ES in the first place.

What's the purpose of the sandbox? To isolate what's inside (in the sandbox) from the outside (the system). By allowing external communications, you're defeating the purpose of the sandbox. Period.

DR_LaRRY_PEpPeR said:

That's absurd! The "holes" are for compatibility, and most [of the built-in compatibility settings] shouldn't have any effect on "defeating" the purpose of Sandboxie. KNOW what the effect of stuff you're opening up is, and you can safely open up a lot. Or leave it alone if you don't. Do you have an idea how much stuff Sandboxie opens up ("allows") by default because it has to? So, no complaints about those from you...? Sandboxie itself defeating its own purpose?

Click to expand...

Yes, for compatibility, which doesn't make them any less dangerous, does it? Also, they're not for Sandboxie's own needs, but rather to make users happy. That's all what it is. If they want to feel safer by allowing IPC between Sandboxie and other security apps or want usability at the expense of decreasing some security, it's their own problem.

As you said, users should be aware of all the implications.

Regarding the default configuration (again, to make users happy), my configuration is far from being the default one. There are no IPCs allowed, no direct access, etc. I'm using Sandboxie for its purpose, solely - isolation.

DR_LaRRY_PEpPeR said:

In NO way would these settings have ANY effect on the security of Sandboxie. Unless there's bugs in ExploitShield that you are then allowing access to. [...]

Click to expand...

There seems to always exist a catch, doesn't it?

DR_LaRRY_PEpPeR said:

In that case, one should not be using ES in the first place.

Click to expand...

Because everyone is looking for buggy code in ES, right? (Or any other app. This is not about ES, at all.)

64-bit...? Then you also (or, instead) need to OpenIpcPath for $:ExploitShield64.exe as well (I never went back and updated my compatibility posts here and on the SBIE forums after realizing that). Assuming nothing else has changed since ES 0.7, that needs additional/different settings... (I haven't used a newer version yet.)

What's the purpose of the sandbox? To isolate what's inside (in the sandbox) from the outside (the system). By allowing external communications, you're defeating the purpose of the sandbox. Period.

Click to expand...

No you're not, period, "defeating the purpose."

Regarding the default configuration (again, to make users happy), my configuration is far from being the default one. There are no IPCs allowed, no direct access, etc. I'm using Sandboxie for its purpose, solely - isolation.

Click to expand...

You really think that? Did you see what I asked? Do you have any idea about how much stuff is open by default, because it has to be? Just because you "think" you don't have any "IPCs allowed, no direct access, etc." (because you don't SEE it), doesn't make it so. How do you think you can access the Internet? How do you think programs can place icons in the system tray, among other things? (Just to name a couple.) Have you closed up whatever resource so you can't access the Internet? No? Why are you OK with that being open, defeating the purpose of Sandboxie? Another one of those dumb users that wants to be happy? (Check Resource Access Monitor to see some other cases.)

Do you want to disallow programs being able to put icons in the system tray, in case there's a bug in Explorer that something could exploit? Well, just..... Oh wait, there is no ClosedWinClass setting, ooops! Better go report the security hole we just found!!1

Amazing. And this is off-topic anyway... Please don't be trying to scare people if they just want to see that their sandboxed programs are protected in the ES GUI.

I'll make it quick, because I also really don't want to too off-topic, because orginally I just wanted to mention that IPCs won't come without their hazards.

DR_LaRRY_PEpPeR said:

No you're not, period, "defeating the purpose."

Click to expand...

We'll have to agree to disagree.

You really think that? Did you see what I asked? Do you have any idea about how much stuff is open by default, because it has to be? Just because you "think" you don't have any "IPCs allowed, no direct access, etc." (because you don't SEE it), doesn't make it so. How do you think you can access the Internet? How do you think programs can place icons in the system tray, among other things? (Just to name a couple.) Have you closed up whatever resource so you can't access the Internet? No? Why are you OK with that being open, defeating the purpose of Sandboxie? Another one of those dumb users that wants to be happy? (Check Resource Access Monitor to see some other cases.)

Do you want to disallow programs being able to put icons in the system tray, in case there's a bug in Explorer that something could exploit? Well, just..... Oh wait, there is no ClosedWinClass setting, ooops! Better go report the security hole we just found!!1

Click to expand...

I'm OK with allowing the very very minimal IPC. Why would I want to increase the attack surface, by allowing more than the IPCs that are actual needed, just to make me feel safer or decrease my security because I want to have as more usability as possible? When I made the decision of using Sandboxie, a few years back, I was ready to made a compromise with my day to day habits. If people aren't willing to change some habits, then maybe they shouldn't use Sandboxie.

Windows 7 SP1 Home Premium x64 production machine, I could not get ES 0.9 to work with NoVirusThanks EXE Radar Pro. ES installed OK, but would not auto-start on reboot, and I couldn't open the UI from the start menu shortcut. As soon as I uninstalled ERP, ES worked fine.

From a user point of view, I would like to see "Chrome is now protected" only once in the logs and not each and every time Chrome is launched. Same goes for all other applications protected by ES.

We've tested extensively alongside NVT ERP Free & Pro and there shouldn't be any problems. The ES startup loader is called Loader32.exe or Loader64.exe. Check your ERP event log to see if there's any blocks of these files. If everything is OK, check your TaskScheduler to make sure there's an ExploitShield entry and it's valid.

I'm just waiting for Webroot to release a stable version of SecureAnywhere which does not conflict with ExploitShield!

Click to expand...

AFAIK Webroot already fixed the incompatibility with ExploitShield some time ago. We haven't tested it so I couldn't say for sure, but I think there's a few Wilders members already using both WSE and ES together.