Sandboxie technical tests and other technical topics discussion thread

You're right again, as you always are. It's obviously not an issue that should be discussed in a technical tests thread.

 

Does anyone know off a download manager with file sniffer that works correctly inside the sandbox? I have experimented a bit with some tools (see links), but I don't think any of them could sniff files. On my old Win XP system, I used on older version of Orbit (with Orbit Grab) which worked just fine, but that was outside the sandbox.

http://www.orbitdownloader.com/
http://www.freedownloadmanager.org/
http://downloadninja.com/
http://www.damdownloader.com/
http://www.eagleget.com/

 

Hi Rasheed, this addon works great with Sandboxie. Installed outside or inside the sandbox.

https://addons.mozilla.org/en-US/firefox/addon/video-downloadhelper/

I know you been looking for something like this for a while, quit searching and grab the best. I found it works in many sites.

Bo

 

I forgot to add that it should work in Opera 12.

But yes, it's a cool extension for Firefox. About the tools that I mentioned, they should all be able to inject a .dll file (the video grabber/sniffer) into all browsers like IE, Opera and Firefox. And some of them do, but for some reason they can't actually find flv and mp4 files.

 

@Peter2150, @bo elam
These phenomena can be deduced but many people including me won't aware unless someone, like MrBrian, pointed out. I could deduce them as I know Windows security mechanisms and how SBIE work, but to be honest never think of them and automatically assumed that Windows and Program Files folder are equally write protected and I can't see other user's data within sandbox. This can cause issue, not design flaw in SBIE but issue can come from user's lack of aware.
Actually I've been keeping Windows folder read-only and put access block to other user's folder so it's not a big deal, but I now have more clear reason to do so.
So I don't understand why you guys make so much argument with MrBrian when he doesn't make any hostile comment to SBIE or its user and always being just like a researcher. I welcome any details or resources, predictable or not.
It's self-evident only after we know the fact, but won't be intuitive for most of us. Please don't assume everyone in here are very familiar with SBIE like you.

 

Yuki, I replied to Mr Brian's posts because I did not want to leave in the air the wrong impression of how the sandbox works. You know, if you delete a program folder in a sandbox and then run the program in the same sandbox, the program wont work. Thats not an issue and there is no reason to be concerned about that,Yuki. I thought it was best to reply so people reading this thread don't get the wrong idea of how SBIE works.

What he calls an issue is actually some of the beauty about Sandboxie. Deleting a program folder and then the program not working in the same sandbox is the same situation as when we install a plugin in a sandbox and then run another program in the same sandbox and both programs interact with each other. Thats just how Sandboxie is and I am glad that it works that way.

Bo

 

Yup, maybe calling it as "issue" is problematic, though I don't know exact difference among similar words (problem, matter, etc...). It can give a reader false impression. Anyway now things are well explained thanks to you guys (including Compu KTed, syrinx).
Just one thing I wanted to point out was, it can be unexpected behavior for many user as he may automatically expect the same behavior as usual desktop, and actually I did.
So pointing out this itself is good thing, but I admit how to do this and what word to use is another story, I myself have to be very careful about it in such online forum, well, not easy thing at all.

 

For me, this is one of the principal concerns - I have to accept that any program, and the sandboxed environment itself could be compromised; but if so, there's no way those programs should be able to get at my confidential data. Of course, there is the exposure where the malware escalates and escapes the sandbox, but that's hopefully harder.

Both for Linux and for Windows at OS kernel level, I'd like to see much more standard and easy to use MAC systems so that your data could be fenced off at a low level from internet apps.

 

That's my observation on Windows 7 x64.

Because EFS won't work with Sandboxie (Anonymous user can't access the certificates), I've taken to having individual sandboxes per user which are located in a Truecrypt automounted drive, with ACL for that user only. Which means that portables not protected by FDE have the user data well protected, whether from other users or theft.

 

Don't think it is a big deal, but for some people, they rightly expect their account-specific information to be a) insulated from other users and b) encrypted on disk. And they may not be aware of the exposure.

Sandboxie doesn't do this natively (and it probably could easily do so using DPAPI plus the username, but then you couldn't browse the folder as now). As I've outlined above though, it's possible to achieve the necessary result in other ways.

 

Let's test the "overstating the obvious" hypothesis in relation to post #792. Methodology: look at all Sandboxie threads that contain in the title "SRP," "software restriction," or "applocker." Note in how many of these threads any user mentions that within a Sandboxie sandbox, path-based anti-exe isn't as strong as might be assumed because \windows, \program files etc. are writable.

I did this test. There were around 20 threads that I could access.

Results: to my amazement, in every of these 20 threads where it was applicable (in some threads it wasn't applicable), at least one forum member noted that path-based anti-exe within a sandbox isn't as strong as might be assumed due to the behavior mentioned in post #792. Well, I guess it wasn't a surprise in recent thread SandBoxIE to harden SRP (software restriction policy) because Sandboxie lead developer Curt participated in it. So it looks like I was wrong, and Peter2150 was right; this is indeed obvious to many Sandboxie users. Oh well, at least I avoided quoting myself for once .

P.S. The last paragraph is fictional. I actually saw 0 mentions in the 20 threads. I skimmed the threads rather quickly, so it's possible that my count could have underestimated the true count. I'm going to post at Sandboxie forums soon so that there is at least one mention.

 

Testing has revealed that the path-based anti-exe sandbox situation differs in some important ways than I had thought when I wrote post #839. More details later but first I want to figure out why AppLocker blocks nothing in v4.14 sandboxes but works fine with v3.44.

 

I think he meant that some AE whitelist Windows and Program Files folder but if these folder are writable it can be security hole. Yup, if it is in sandbox and when you set either start/run restriction or read-only/access block to it, nothing matters. But if a user don't know those advanced settings this can leave theoretical threat that, an exploit which tries to write to those folder w/out elevation will firstly search for permission of those folder and sub folder (usually there're some writable folder) and then will write executable into the writable folder and execute it. This way the malware can affect all user, besides a malware hidden in those folder won't stand out for most common users.
When a AE whitelist those folder except originally writable folder, then malware will be able to launch inside sandbox while not in real system.
As I said, workaround is easy, just put start/run or access control and even w/out this still malware will be contained in sandbox so can be easily deleted. It's not an issue, but for those who don't know these things and in certain condition (quite likely? I say No.) there can be theoretical risk.

But I think this story is already answered and solved, is there any need to dig in more unless new discovery is made?

 

Unless new discovery is found I feel secure as possible using Sandboxie. I have set Programs and Windows folder.
If malware tries to download (common location is temp folders) I have that covered. Browser is equipped with filtering/add-ons and firewall hardware/software combo is monitoring inbound/outbound connections. Restrict Internet and Start/Run Access also and run everything in a restricted user account.

 

@142395: All of your last post is right, except that I was originally mistaken (before I actually tested it myself) about the path-based anti-executable aspect of this. When there is a changed executable in a sandbox, that changed executable is put in c:\sandbox (or whatever your sandbox folder is). The rest of this paragraph is true for SBIE 3.44 but I'm not sure yet about SBIE v4.x (thanks to Peter2150 for the tip). If a changed executable is executed in a sandbox, the system sees the changed executable as starting from c:\sandbox (or whatever your sandbox folder is). So here is some quite good news: if you block execution from c:\sandbox, I believe that the issue in post #792 is taken care of, as far as executable content is concerned. However, blocking execution from c:\sandbox will block execution of legitimate changed executables in a sandbox also, since there is no discrimination between desirable and undesirable changed executables.

There's more to the post #792 story though: change of non-executable content in a sandbox can possibly have negative security implications. As an example, any sandboxed process can change a virtualized copy of the hosts file located at C:\Windows\System32\drivers\etc.

 

Here is the NoVirusThanks Exe Radar Sandboxie configuration change that Peter2150 referenced: http://novirusthanks.org/help-files/exe-radar-pro/#sbie-erp.

 

I must admit that I did not fully understand this "potential security problem" that you pointed out, but if you want to have complete control over sandboxed apps, you could use tools like EXE Radar and SpyShelter. The first one monitors process execution, the second one monitors for malicious behavior. Of course SBIE already blocks quite a lot automatically.

 

Or use Sandboxies settings. Sandboxed applications can be set not to have access to the entire Windows folder or specific files inside Windows. Or they can be set to Read only Windows, Host file, so sandboxed applications can read them, use them but not make changes to the file or folder inside the sandbox. Myself, I don't do any of that as I don't see the need.

Bo

 

Could you explain how any sandboxed process can change a virtualized copy of the hosts file?

For example if Windows explorer is sandboxed and I try to edit/change the hosts file

1. I have to allow rundll32.exe (that's controlled)
2. I have to allow/choose program to open hosts file (notepad for example-that's controlled)
3. If I try to edit/change host's file and save changes I'm not able to implement those changes.

 

In this particular case, the changed hosts file in a sandbox might not matter to programs running in a sandbox because the code that loads/reloads the hosts file perhaps isn't under Sandboxie control, so it doesn't see the changed hosts file.