Sandboxie technical tests and other technical topics discussion thread

I wasn't thinking of you.

 

Okay, thanks!

 

Ok, how about Sandboxie and Mailwasher Pro? I have never been able to get Mailwasher to work seamlessly with Sandboxie. I did look at the Sandboxie forum, but little info and old. This is an internet facing app and should be boxed up.

 

This advice by Tzuk might work, give it a try, focus.

http://forums.sandboxie.com/phpBB3/viewtopic.php?f=11&t=16673&start=15

Bo

 

Thanks Bo, I have seen that post and tried that fix but it didn't solve the issues. I had a feeling that the OP on that post just let it go and worked around the problem. Probably not a lot of Sandboxie/Mailwasher users out there so there may be some basic incompatibly that has not been worked out. I'm not frantic about this, but it may serve to change the topic from Chrome .

focus

 

The OP in that thread is our good friend Page42, perhaps later when he sees your post he ll tell us if Mailwasher is working or not for him with Sandboxie.

Bo

 

Thanks, I forgot to reply, but some more info without any in depth details would be nice. I mean, I wonder how the heck this is possible if SBIE is blocking direct write access to the file system and registry. On top of that, it runs all apps on different desktops and isolates inter-process communication. So were is (or was) the flaw and how did you discover it?

 

I must have missed that part about him not willing to give any more details.

 

Yuki, I'm bringing you the entire and exact reply from Bromium Labs what they sent to me (please, read):
"Hi,
I tested with SBIE4 and indeed it is quite different and has security improvements over what we tested in our report. Great job by the author!
However, our kernel exploits still work flawlessly – no issues there. You need to remember that SBIE3/4 (and other similar app sandboxes) are kernel mode drivers and they will always have some fundamental limitations. Blocking access to specific DLL’s is far from a practical use case as you have no idea where the next patch is going to come (BTW similar capability has been available in HIPS technology for several years and very few people use it)
Once time permits, we’ll probably update our analysis with the latest SBIE4. However, this is not our core focus, the idea of this research was to simply enumerate the fundamental limitations of application sandboxing tech."

I hope this answer satisfies you, Yuki.
Cheers and my honest apologies to you, Yuki, and to FleischmannTV for making you extremely tired and for misquoting you and your posts.

Just for the record, Sandboxie when properly configured with internet access restrictions start/run restrictions did actually protect against the rest of Bromium tests: keylogging, remote webcam/MIC access, Clipboard hijack, screen scraping, steal files, network shares access-the only thing Sandboxie could not protect against were kernel exploits, the same as Chrome, so in those tests Sandboxie was actually proven to be equally tough as Chrome.
Against user-mode exploits Sandboxie was equally tough as Chrome as well.

 

Pete is right, don't ask him!
If you think criminal can't build exploit until he get exact details, it's wrong. Sometims even just a bit of hint can be enough. Besides, asking such question to founder is no manners in this field (not intended to offense).
Who I quoted sometimes, the guy who happned to find Android 0day, had been suffered much cuz he was not allowed to disclose it. As is often the case of Android, it needed a year to be patched for most of major devices. What he could do for his friend was just recommending to use Chrome instead of stack browser w/out disclose vuln or w/ only general facts. If you don't care Google translation, this is his confession about that.
https://translate.google.co.jp/tran...ogspot.jp/2013/12/JVN53768697.html&edit-text=

 

Well, I guess you're right, but it would be still interesting to know. And there's no need to be overly paranoid, there are quite a lot of exploit details available for all kinds of apps, unpatched or not.

 

Yes, I really wonder what the developers missed.

 

Can somebody tell me if this is desired behavior or a bug?

In a VirtualBox Windows 7 x64 SP1 virtual machine that's fairly close to all default settings, I installed Sandboxie 4.14. I then switched to a standard account. In the standard account, I started a sandboxed Windows Explorer. Using the sandboxed Windows Explorer, I tried to delete c:\windows\regedit.exe. I expected this to fail, given that this is a standard account. However, the delete was successful. Similarly, I was able to modify Windows executables from the standard account. The changes were virtualized, but I didn't expect to be able to do these types of things in a standard account.

 

Or can someone at least test if this happens on a physical machine also?

By the way, a UAC-protected (UAC slider set to max) admin account exhibited the same behavior when I tested in VirtualBox.

 

Mr Brian, you can delete files like c:\windows\regedit.exe while running a sandboxed explorer, the deleted file is just a copy of the real file. I use an administrator account and never used standard accounts so I don't know if things should be different when using one.

In my W7, I have UAC on and I dont get a prompt when deleting regedit in a sandboxed explorer.

Bo

 

Thank you for confirming this on a physical computer .

IMHO, this is rather concerning; this is privilege escalation. As a result of this, theoretically some exploits that would have been stopped at a non-initial stage without Sandboxie (or executed unsandboxed if Sandboxie is installed) will succeed when sandboxed with Sandboxie. Regarding integrity, the damage is apparently contained to a sandbox. But remember that violations of confidentiality might not be reversible.

 

Consider this as an example: You're using Windows 7, and UAC is not disabled. You view a pdf that exploits a vulnerability. The shellcode running within the pdf viewer tries to download a malware executable and write it to c:\windows and then execute it. Suppose the malware executable sends some information (i.e. there is a violation of confidentiality). If this exploit runs unsandboxed, it should be stopped when it tries to write the malware executable to c:\windows; thus there is no loss of confidentiality. However, if this exploit runs sandboxed, the malware executable might run and thus violate your confidentiality.

 

Your example cant do nothing to me. If the malware attempts to start and run, both, my Windows explorer and Foxit (PDF Reader) sandboxes are Start Run restricted. So, it is likely malware.exe would be blocked from running. If the case was that the malware hijacks the PDF reader to have access to the internet, I block all programs from having access to the internet (Windows explorer and Foxit sandboxes).

Bo

 

Same thing happens with Sandboxie 3.76 and 4.02.

 

@MrBrian

As explained already you can delete regedit.exe in a sandboxed Windows Explorer in
a admin. user account and a Standard/LUA. This however is within the sandbox (isolated) and not on the real
system. When you close & delete the entire contents of sandboxed explorer and then run
sandboxed explorer again regedit.exe will be listed.

Try adding C:\WINDOWS or C:\WINDOWS\regedit.exe to Read-Only Access (ReadFilePath) in
Sandbox Settings and then try to delete regedit.exe. Should not be able to delete it.