Sandboxie technical tests and other technical topics discussion thread

I hate to say it but MrBrian does have a point. I'm one of those ppl with restrictive sandboxes but those running a default box may run into such an issue. I'm not so much sold on the argument that such an exploit would 'need' to save a file a to the windows folder then launch it. Disregarding the restrictions of files created to system folders in a sandbox and then not having the UAC prompt for such a created file does present a security issue and is not very 'security conscious' for a security product. It seems like something that 'AppGuard', which I also happen to use, or even the run/net restrictions available for boxes would help prevent. Even without an extra program, the rules available within the sandboxie software can solve such a problem- but by default they do not.

At the same time, assuming an exploit runs (sandboxed or not), is able to get admin privileges, then downloads, saves and launches a file which then reads and reports data from the drive, (say confidential data as he did) the argument essentially becomes irrelevant. The fact that sandboxie by default allows such a file to be (virtually) created in a system directory ignoring such UAC rules may be an issue but not if its advanced enough to save to user space, grab admin rights or otherwise go undetected and get that far (in a sandbox or not) does windows itself stand a chance? Most likely not...but the default box rules may open (1 hole) an opportunity for attackers to abuse the default rules of sandboxie without gaining admin privileges. By default however there is nothing that is BLOCKED/prevented as far as reading for goes for USERS aside from any content stored in a separate EFS protected account.

I get what he's saying and as far as DEFAULT sandboxie rules go he does have a mostly valid point IMO. This isn't why I run untrusted (90% of internet facing) apps sandboxed in the first place - but it is similar to the reason that I have rules set to block the paths to confidential data....if you want to protect something and are using sandboxie, the folders or files SHOULD be blocked (ClosedFilePath=) in your sandboxes anyway...I mean DUH!

I certainly hope to see a fix for this potential issue in the default rules. I'm not at risk from such an attack but there is no denying it is valid for the default rules. At no point has sandboxie claimed to prevent exploits or virii from running. It only prevents them from persisting or spreading. (If you auto-delete boxes!) This is why I recommend a good AV, Exploit Blocker, keystroke encryption and firewall/HIPS in addition to a solid sandboxie setup.

(The Block Process Access Add-on can also be helpful vs malware!)

and I most likely confused others along with myself so, so ya baby ya!

 

I'm not sure if you understand user-mode exploit tests as all of tests you mentioned here are not about that user-mode exploit, but anyway thanks.

 

Yup, will be interesting but you have to wait until patch is released.

I'm not saying it cuz I very fear the exploit, but cuz it is common practice known as repsonsible disclosure. No, you can't find details of true 0day except for the case it is already abused. Once Google disclosed a bug before patch, and it attracted lots of criticism.

Interesting finding, thanks MrBrian.
I wonder if it is intended behavior, as I can't imagine the situation this is needed or useful even for testing purpose. I can't see why they don't keep privilege hurdle, regardless of it has security impact or not.

 

Mr Brian, I think I have the explanation. No expert here but I think this makes sense. The file you delete is not c:\windows\regedit.exe but a copy of regedit, located NOT in Windows but, for example in my W7, in C:\Sandbox\Bo\WindowsExplorer\drive\C\Windows\regedit.exe.

Bo

 

Yuki, I'd like to ask you during this week (I'm not sure when, exactly, maybe on Wednesday, not before, because I can't catch enough time) through pm about my potential security setup that I have on my mind, I'd to ask you, because you seem to be a very reliable person when it comes to this, because I want to fill my holes in security and protection on my computers, hopefully moderators will not delete this message since it is not part of the thread...

 

I agree. In my first post I did state, "The changes were virtualized...."

 

Right, and because of UAC I would guess that most exploits in recent years save the second stage malware executable to a folder that doesn't trigger a UAC prompt (without Sandboxie installed).

 

Right, but just to be clear, the issue that I noted might make it easier in some cases for an exploit to complete its intended attack in a sandbox than unsandboxed (or without Sandboxie installed).

 

Right, it's only virtualized copies of files that are affected.

By the way, this issue isn't specific to Windows Explorer. It also affects Command Prompt. I would guess that it affects every process that runs sandboxed, but I haven't tested further.

 

You're welcome . I would guess that it's intended behavior. I haven't found any Sandboxie forum reference to this issue thus far, which amazes me because this is "101" level testing IMHO.

 

Here's a demonstration that changed virtualized file copies are actually used in a sandbox:
1. In a standard account, I ran Command Prompt sandboxed.
2. I issued command cd \windows
3. I issued command copy write.exe explorer.exe and answered "y" to the overwrite prompt. This overwrites the sandboxed copy of explorer.exe with write.exe.
4. In the same sandbox, I clicked menu item Run Sandboxed -> Run Windows Explorer.

WordPad opened instead of Windows Explorer.

 

In a standard account I tested Notepad sandboxed. I clicked Notepad's File->Open, then in the file dialog box deleted folder c:\Program Files (x86)\Windows Media Player. In the same sandbox, I tried to open Windows Media Player but it wouldn't launch.

All three programs that I've tested sandboxed have exhibited this behavior.

 

Sandboxie 3.44, released February 2010, has the same behavior regarding the issue that I noted in post #792.

 

After deleting the Windows Media Player folder in the Notepad sandbox, without deleting the sandbox, if you run a WMP video out of the sandbox, the video its going to open. If you try to run WMP in the sandbox after deleting its sandboxed folder, WMP not launching its how is supposed to be. No issue.

Bo

 

Can anyone give a prior explicit reference to this issue anywhere?

 

From Permissions on C:\Sandbox:

 

@Peter2150: No need for the dismissive attitude. This is news to some others in this thread.

 

I agree, I also believe that I already gave the explanation for why their is no prompt from Windows or UAC. But here is again.

Mr Brian, Why expect to get a prompt from Windows or UAC when files and folders that you delete in the sandbox are not Windows files? The deleted files and folders are created by you, the user, their path does not lead to Windows or Program files.Sandboxie can fool many programs into believing the sandbox is the real system. But fooling Windows into believing that C:\Sandbox\Bo\WindowsExplorer\drive\C\Windows\regedit.exe is a Windows file? thats not going to happen. I believe thats why you are not getting the prompts that you are expecting to get.

Mr Brian, if you are not satisfied, I ll ask Curt if you want but really, I don't think that should be necessary. But for you, I do it if you want.

Bo

 

@bo elam: Thanks for the offer, but I think that Curt's reply in post #817 is sufficient, at least for my sake.

 

Here is another technical issue that perhaps some people here might not be aware of.

From Sandboxie + Windows Mandatory Integrity Control:

By my testing, this issue is present in Sandboxie 4.14.

 

Here is a more succinct version: with default settings, every file that's created in any sandbox is accessible by all user accounts on the computer by browsing c:\sandbox. Is that an accurate statement?