Sandboxie technical tests and other technical topics discussion thread

No, and from a development point of view, and if you're restricting your client to Windows, I don't think it's actually necessary. Chrome is using multiple processes and IPC which makes things rather more complex, whereas for an email client, I think there would be a reasonable single process sandbox alternative using .Net threading impersonation and permission sets etc. To the extent you trust that.

The real issue is that, as normal, functionality comes (way) before security.

 

Thanks for the info, so you mean you can assign different permission sets to threads via .NET?

 

Yes, as well as switching principals on the thread. Obviously the process address space that the thread is running in is potentially open to malware once subverted, but this prospect is fairly well restricted by managed code, as long as the app is pure managed code. An awful lot of protection is built in through the compiler and object orientation.

I think the problem is that people writing for open-source cross-platform software are not going to be using .Net to a great degree.

 

I haven't got any problems with these posts, and people can learn from it. But at the other hand, months ago I already pointed out that SBIE does not automatically protect against certain stuff like for example global hooks (key-logging) and code injection. These are things that might indeed be used in a malicious way inside the sandbox. So you need to either lockdown the sandbox with "Restrictions" and "Resource Access", or you can use third party tools.

 

So, basically you are both saying that Sandboixe is totally useless? This can be done with SBIE's configurations settings, like I said before, properly configured Google Chrome=properly configured Sandboxie (with many sandboxes, each with its own application and web-browser) when it comes to security and protection.

So, basically you are both saying that Sandboixe is totally useless? This can be done with SBIE's configurations settings, like I said before, properly configured Google Chrome=properly configured Sandboxie (with many sandboxes, each with its own application and web-browser) when it comes to security and protection.

 

So it's not as complete sandbox as process isolation, yup it's a nature of thread and unavoidable I think, but will be much better in performance point of view.

I heard .NET is pretty secure framework in other place too. It's good news for me, though I don't know why it's not popular in closs-platform OSS. Maybe thanks to allergy to Microsoft and unpopularity of C# (and even whole OOP recently)?

We're talking about different things. I think it's actually a bit off-topic.

 

Possibly I read too much myself... Anyway, tho I appreciate those your reports much, they are not about changing system parameter (more easily than real system). Also as a note, SBIE actually intercept global hook and converts it to local app-specific hook. http://www.sandboxie.com/index.php?BlockWinHooks
(I guess SBIE intercept SetWindowsHookEx() call by sandboxed app and change its parameter(s))
Oh, well, maybe "need" is bit too much as best practice of emptying all sandbox before any sensitive activity will protect you from those threats most of times. I guess "better to do" or "I recommend to" is more suitable word, or not?

 

I conducted tests.

1-1. Firstly, I can access Facebook via SBIEd IE.
http://i.imgur.com/Fl38oVD.png
1-2. Overwrite hosts in SBIEd cmd.
http://i.imgur.com/0rJAEoz.png
1-3. Tried to access FB via IE again. All addons are disabled just in case.
http://i.imgur.com/PDelN4F.png
1-4. Access is redirected to 127.0.0.1 as I can see message from Hosts Server.
http://i.imgur.com/tB2dOXB.png
1-5. Logs of Hosts Server.
http://i.imgur.com/ysvfROl.png

2-1. If I try to edit .reg file, I get this warning as I have added .reg to my SRP policy.
http://i.imgur.com/5uPFzXN.png
2-2. Delete CodeIdentifiers key.
http://i.imgur.com/M9FQhoL.png
2-3. Now I can edit .reg w/out warning.
http://i.imgur.com/EkZSYU5.png

I did another test.
3-1. When I am LUA, I can't delete certificate.
http://i.imgur.com/L3Mhr5p.png
3-2. Neither on IE.
http://i.imgur.com/6OFM5ou.png
3-3. But I can delete certs in SBIE tho I'm still LUA.
http://i.imgur.com/OBwpGrn.png
http://i.imgur.com/YRaMo3h.png
3-4. Somehow I couldn't find SSL connection issue on SBIEd IE so far. Also some code sig didn't affected. But as seen below, some software such as KeyScrambler can't be verified under SBIE thanks to deleted certs.
http://i.imgur.com/MTZiaxz.png
http://i.imgur.com/JsviW9p.png

 

Well, I had to think three times, not twice. lol
In SRP, IIRC what determine execute or not execute is parent process and this led to some bypass in java or in Office.
So maybe that we had to be able to predict this.

 

I think it's more to do with graphical frameworks and development environments available cross-platform. C# and .Net is popular and productive, but in restricted environments. But the problem with C++ is that it is far more reliant on coding quality, and there's far more opportunity to leave huge holes - which are very hard to audit. We badly need, from a security point of view, some code base and language environment that is much easier to verify and code safely.

And then there's the whole focus on smartphones and browser, including the Javascript morass of libraries - unproductive and hard to secure. There's not even any code-signing for what gets delivered to your browser, and who knows what's in all these libraries you need to get a productive environment. Ughhh from a security point of view. Long live Sandboxie!

One other benefit of the in-process threading model is that system-protected objects like SecureString and DPAPI (to the extent you trust that) - can be made to be restricted to process-only access. So you can have secrets that are in-memory (and optionally encrypted), and only available to the process itself (depending on OS integrity of course). Once you start handing these across a process boundary (as in IPC), then you have a problem, and they are vulnerable to debugging tools.

 

Simply block cmd.exe and nothing mentioned above would be possible, end of story.

 

I know little about programming, sorry for my ignorance. Do you mean lack of grafically user-friendly cross-platform IDE for .NET (like eclipse for example)?

Can you clarify bit more, why javascript libraries are so unsecure?

Well, if one fear state-sponsored or national agencies then uging Windows itself can be regarded as risk, you know, but my threat model is not that.
Yup, even I as an amateur can imagine IPC for sharing (rather, copying?) info is a problem, can be attack surface, besides consume more resorces.
One question: assume you employed proper encryption in memory, then your program is compromised and attacker get arbitrary code execution, can attacker decrypt and steal those info? And in what condition (e.g. they need to know brabrabra...)?

Please, reply via PM if you don't mind as this will be regarded as off-topic.

 

I hope you speak only after you understood things. Non of them rely on cmd.exe, if you want to completely block them you have to put access control or read-only access to Windows and Program Files folder and HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer (I rather recommend whole Policies key), besides that's not the focus of the discussion at all.

 

Will do, except that I'd observe that the insecurity of Javascript in browsers is not so much to do with the language itself, but the way code is distributed and has full access to the browser functionality. A page load can have code from anywhere, not even https, executing within your browser environment. When a site says, here's jquery, how do I know that's true or what's been modified? Or Mitm would be easy too.

The whole presumption of browsers is that they are fully sandboxed and have no cross-site privacy impact. We know that's not true, hence Sandboxie (amongst other controls).

 

Thanks for your tests . I wonder why your hosts file test result differs from that of Compu KTed and mine.

There are probably a lot more post #792-type tests that could be done regarding Windows and third-party software configuration data that is writable (virtually) without admin privileges inside a sandbox (but would have required admin privileges outside a sandbox), but I'll leave that to others to explore.

 

Yes I know, I was just giving an example of stuff that can be abused in theory, I also discussed it back then with MrBrian. The end conclusion is that SBIE has chosen not to block all behaviors inside the sandbox, for usability reasons. Because of this approach, there might be certain security risks. So that's why I think it's best to use third party tools to monitor apps even inside the sandbox, then you would not have to worry about "modification of host-file", and related attacks.

 

3 people, 3 different results. lol
@Compu KTed have you checked "Read only" in file permission (not referring to SBIE setting, but Windows' file property)? I confirmed if I check I get "Access denied".
@MrBrian can you re-test hosts things after:
1. Delete DNS cache and disable DNS Client service
2. Disable web sites' cache and database on IE, clear all history items (of course except data for your favorites which is separated from the rest), and even add -private option for your IE shortcut.
3. Reboot your machine just in case.
Also please maku sure that reference of LMHOSTS is checked in both IPv4 and IPv6.

 

If your referring to Windows hosts file test then yes you would get access denied
and 0 file(s) copied if the hosts file is checked "Read Only".

Hosts file "Read Only" unchecked would result in 1 file(s) copied.

If you add hosts file to "Read-Only Access" in Sandboxie and uncheck
Read Only in Windows hosts file then result also would be access denied
0 file(s) copied, but you probably already new that.

 

I'll just say this, if any of those mentioned installers are infected I would be already infected with 1000 malwares, but guess what they are not! Please don't be like hyper-paranoid conspiracy theorists, because you have no reason to be.
Against infected websites Google Chrome protects excellent based on your posts (I'm not sure even if this is true or not), but the fact is I have never been ever infected even though I visited hacked and infected websites without any form of protection, and guess what, nothing happened, I think there are many people here who are simply too paranoid beyond any form of realism.

If you do know what you're doing and trust no website, than you are fine, but if you have family that clicks everything than use Sandboxie on top of each, every and all web-browsers (including Google Chrome as well), everything you, Safeguy and Hungry Man said about Sandboxie sandboxing Google Chrome is also purely hypothetical (including targeted attack hypotheses and increased attack surfaces), like everyone said; real experts need to test both form of sandboxes, Google Chrome on its own and also Google Chrome must be tested under Sandboxie and its protection and restrictions/proper configuration, than, and only than, you can say, OK now we have evidence for this hypothetical claim or for that hypothetical claim, or the results are completely different from what you are only assuming from any real credible evidence, heck there are mo eve circumstantial evidences for each, every and all forms of claim, let alone direct and irrefutable evidences.

 

Off-topic
Speaking of signed installers I found this handy, I believe, tool from DigiCert:
https://www.digicert.com/util/
Just run the program and click the blue link "Check Signature" and it displays relevant info nicely and very fast, instead of right clicking a file and bla bla bla.

Spoiler

http://i.imgur.com/wXiS2jo.png

If you know a better tool to work with please let me know.

 

in nearly 20 yrs downloading and installing software, not once have I been infected by one when I downloaded from known, trusted sites. In fact, I don't bother checking hashes or digital signatures as long as I download form sites like softpedia, sourceforge, Filehippo, or the developer's site. If something doesn't look or seem right during installation, I can just routinely restore in mere minutes with a recent image, anyway. No need to worry about rogue installers or waste time checking hashes and whatnot.

 

http://www.sandboxie.com/index.php?BlockWinHooks
referring to this URL that a user posted in an earlier thread... could this be the cause of the incompatibility between Sandboxie and SpyShelter?

 

OK, thanks, so basically this is how you can know if installer is malicious or not using SSL Certificates, hey MR. X can I know your security setup, I believe it's a combo of Sandboxie and AppGuard, anything else?

 

Exactly my point, I know plenty of advanced programmers and web-designers who don't use Sandboxie, AppGuard, internet security, they even don't have router protection like I do or anything else, they use full protection of their own Windows systems (like Windows 7 and 8.1 and even Windows XP Pro Service Pack 3) and they download all sorts of things and they are never infected, mostly they have Avira free antivirus (for removable drives and similar), they use UAV/LUA and security setups in a way like Windows Security does and that's pretty much it.

 

Yup, I asked cuz you reported you couldn't alter the hosts in SBIE. So maybe you had already checked Read-Only when you tested?

Sigcheck is also useful if you don't care CUI, but I admit for just checking sig, Digicert's tool will be better.