Icesword cuts through Sandboxie like butter

Which "this" are you referring to?

cheers

 

icesword!

 

Google is your friend

From http://www.techsupportalert.com/best_46_free_utilities.htm

[1] http://www.f-secure.com/blacklight/cure.shtml Windows 2000 and later, 911KB.
[2] http://www.xfocus.net/tools/200509/IceSword_en1.12.rar <= slow Chinese site, 565KB
[3] http://tinyurl.com/ckqsn <= Local mirror for IceSword

cheers

 

Just in case somebody is reading this without reading the rest of the thread, I'll repeat what I said here in a later message and in the other: unlike what the subject says, IceSword is actually NOT able to break out of Sandboxie in normal conditions. I mistakenly thought I had found a Sandboxie security flaw at first, but this was not the case: Sandboxie DOES block IceSword from running in kernel level, unless IceSword is executed outside the sandbox before.

If IceSword is executed outside the sandbox, it loads its kernel driver, which is not "unloaded" when the IceSword program is shut down; only because of this reason Sandboxie is unable to stop it later on. If you start IceSword only in the sandbox, it won't run, because Sandboxie will block it from loading its driver. So this is not a flaw in Sandboxie.

 

Hm , I recognize I didn't test it at the time this thread was active, as I didn't want to be polemical, but now that you raised it back...

I've tried the same procedure as yours, loading Icesword out of BufferZone, using it and closing it;
here I sent Icesword into BZ, and I must say my result is still different than yours: though the driver was previously loaded, Icesword is unable to gain access to it, and I get the "Initialization Failed[3]" error message. Icesword is running in Task Manager, but the GUI doesn't load, and you can't kill its process (which is using 80-90% cpu in such circumstances). So yes it's loaded somehow in BZ, but in a way you couldn't use it: seems BZ driver protection is complete: it can't stop it neither, but can prevent its access outside the BZ.

Cheers,
nicM

 

Should apps like Ice Sword unload all drivers or is it proper that they don't?

 

Well, I don't think it really matters whether a malware reaches out of a sandbox or not, if it was already allowed to work in kernel level outside of the sandbox before: it sure would have been able to do any damage it wanted anyway, and the defense mechanism could not be trusted anymore (they could have been modified by the malware itself). The flaw in my analysis of the scenario in the first message is simply that I had not considered that IceSword could have left the kernel modified even when the executable was shut down (which in fact it did: its driver was still loaded).

The purpose of the sandbox is to test the file and contain the possible malware, stopping it from modifying the operating system or files outside the sandbox. If the malware had the 'upper hand' already (working as part of the kernel), and it 'knew' about the sandbox, the sandbox mechanism might be toast already.

I don't consider that Sandboxie scenario a flaw at all: the purpose of Sandboxie is to contain anything executed in the sandbox, not outside of it.

 

This one installed ok for me:

http://www.snapfiles.com/reviews/Sandboxie/sandboxie.html

 

Yes, I concur , is just a difference of behaviour in communication between the sandboxed zone and the normal one: in all case NOT the way the sandbox protection is mean to be used, for both Sandboxie and BufferZone.

Cheers,
nicM

 

Btw, it was a false alarm, Sandboxie really works, also on my system, read my post in the SBIE forum.

http://sandboxie.com/phpbb/viewtopic.php?t=110&start=15