ExploitShield Browser Edition 0.9

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.

 

Will it work with Sandboxie?

 

You need to configure some things under Sandboxie to make it work. Details at http://www.zerovulnerabilitylabs.com/forum/viewtopic.php?f=2&t=173

 

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

 

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.

 

In that case, I'll stay with Sandboxie.

 

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.)

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.

Don't worry about this zmechys.

 

Nonsense. This change just allows the ExploitShield EXE to communicate with the injected ExploitShield DLL within the sandboxed browser.

 

Absurd?

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.

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.

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

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

 

No luck on the Windows 8 64-bit computer.

 

Please keep on topic or open another thread for discussing the merits or lack thereof of interprocess communication as a security risk.

When it comes to ES and Sandboxie compatibility, as @DR_LaRRY_PEpPeR pointed out they can be made to work together @zmechys.

 

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

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.

We'll have to agree to disagree.

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.

And, this is not about scaring anyone. lol

 

My ExploitShield Browser does not work with Sandboxie. It's my fault.


I've noticed a strange thing, -10 Shielded Applications.



=======================================
The log windows does not show any notes.

 

The "shielded apps" counter is a known bug:
http://www.zerovulnerabilitylabs.com/forum/viewtopic.php?f=2&t=147

 

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.

 

Browser Edition 0.9

Works perfectly with my GPO-locked down setup with lazy Admin easy installation escape . So for corporate environments that must give good hope.

The 0.7/0.8 error I had is gone, Z icon shows/process loads/dll inject as expected after Chrome/Chromium update, good work

 

+ 1 even if i work in a simple LUA account (8 x64).

A very, very good job!

 

Installed and running great, no problems at all

 

thanks PB, working great here to.

 

So far, it is working fine here, too.

 

I can't wait to put my hands on this software! I'm just waiting for Webroot to release a stable version of SecureAnywhere which does not conflict with ExploitShield!

 

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.

 

I tried the version 0.8.1, and it was great. Looking forward to trying the latest version.