Name-based checks of known applications (chrome.exe etc) [Security issue]

[typpos]

Sandboxie identifies well-known executables based on file name to change security behaviour. This looks like a security risk.

Example 1

A default template for "GroupChromePrograms" gives "Direct" access to folder "C:\Users\typpos\AppData\Local\Google\Chrome\User Data\Safe Browsing". Compile the following .NET 5.0 C# 9 application (with your own user name in the path) and rename the executable to "chrome.exe". Keep the executable outside of the sandbox and run it sandboxed. Sandboxie now identifies this executable as Google's Chrome and gives direct write access to a folder outside of the sandbox:

System.IO.File.WriteAllText(@"C:\Users\typpos\AppData\Local\Google\Chrome\User Data\Safe Browsing\Typpos was here.txt", "Hi from typpos!");

Example 2

Internally, sandboxie checks for executable name "cvh.exe" and if found running, raises an SBIE notification. Rename any executable you have (outside the sandbox) to cvh.exe and when executed in the sandbox, this notification is raised. This behaviour cannot be modified by changing templates.

Suggestions

1. Change "known application identification" to safer methods. For example, Chrome.exe is a signed executable.
2. Ability to disable non-templated special behaviour for a sandbox, unless such behaviour is confirmed secure. Example 2 above seems to pose no risk, but there are numerous such tests all over the code base.
3. Change the user messages when adding templates to make it clear that they are rather broad in scope. As a user, I simply assumed that such templates somehow magically enable some trusted applications to work, but never looked at details to understand that this actually punches holes for arbitrary (suitably named) programs.

[Coverlin]

'The example does no justice to the claim' ; but i agree that image names aren't great in comparison to a mechanism to determine the apps integrity.

Remove the lines from the sandboxie.ini if paranoid:

Template=Chrome_Phishing_DirectAccess

(A quick way is by using a text editor find and replace fuction and add # infront of the lines to comment them , use sbiectrl to reload ini and do a action that will cause sbiectrl to edit the ini , example "set layout and groups" , just open and press ok on the window and sbiectrl removes the template from all boxes)

It's not a security issue since the template in question is using OpenFilePath OpenFilePath=<ChromePrograms>,%Local AppData%\Google\Chrome\User Data\Safe Browsing* Note: For security reasons, this setting does not apply when the program executable file resides within the sandbox. This means that (potentially malicious) software downloaded into your computer and executed, cannot take advantage of this setting. If you download a virus chrome wannabe in the sandbox it won't be able to do anything ...outside the sandbox

If you get the virus while not sandboxed then thats not on sandboxie , you're scr3w3d either way , if you run it sandboxed it will drop files in the folder that has direct access or modify the existing ones as per the template rules . 'Don't blame the AV if you disable the protection'. Create a dedicated box with proper settings if you want to test sketchy apps.Instead of running everything in a single box example: dedicated chrome box

Example 2 isn't security risk at all only a annoyance

[typpos]

Thanks. Fair points.

Note: For security reasons, this setting does not apply when the program executable file resides within the sandbox

That's not my use case: I often run executables sandboxed even though they're outside the sandbox. For example, download stuff, then right-click-context-menu "Run Sandboxed". Or, attach external drive, run applications from there. I suspect similarly for mounting an ISO (which I believe can't be done from inside a sandbox) and then run stuff from the mounted drive sandboxed. To get to your use case I would have to copy the entire fileset into the sandbox before execution, which would make me wonder about the purpose of the "run sandboxed" context menu.

Remove the lines from the sandboxie.ini

You're right about how to configure this, but when I install an application and it suggests to add some templates on first run for compatibility, then I would not expect users to understand all the subtleties. Hence my suggestion (not claim). I guess I lean more towards usability/safety. If a template says it applies to "Group: Chrome Programs" then a user would assume this to mean the actual browser, not any odd chrome.exe and a range of other unstated file names.

The example does no justice to the claim

[smiles] The two examples are instances of two classes of in-code behaviour I'm concerned about and suggest to be reviewed. They don't claim to show a serious security hole. I wouldn't list it here had I found one.

Anyway, what feels important to me and the basis for my suggestions earlier:

1. In-built decisions for known-apps (template related or not) in combination with how these apps are identified don't create security holes, and some reassurance or a review by devs of the various places in the codebase would be great.
2. Templates and config settings don't muck up "normal" users who don't dive into the details.

Btw, I'm not fussed if this issue simply gets closed. I now know how it operates and can make adjustments.

[DavidXanatos]

Using name.exe only is something I also don't like eider, but I'd rather want here to be able to specify a full path or a partial path. Not for security reasons but for usability reasons.

Security of a name.exe approach is not that much worse than checking if chrome has the right signature. The problem here simply is that when you are a malicious program that assumes chrome.exe will be allowed to do X and you will not, than sure, you could rename yourself to chrome.exe. But if that ability wouldn't be on the table because signature checking or whatever, than you just start chrome.exe and inject some of your code into it with CreateRemoteThread or alike and voila you can act as chrome.exe.

That is why to some extent you wont find just a personal firewall anymore on the market but only various kinds of security suites that all do more than just filtering packets based on an application's path.

The same issue is present within a sandbox, any application running within it can mess with other applications running in the same sandbox at the same security level.

So you realistically must assume that if any application inside a given sandbox is allowed to do X than any malicious process within that sandbox if it wants will be able to also do X.

@typpos with regard to your specific use case: if a non sandboxes application tries to create a copy of itself called chrome.exe than the copy will be sandboxed and those OpenFilePath wont longer apply, so its not that much of a risk.

[typpos]

Thanks, David.

My workaround will be to disable all templates and I'll assume the hard-coded name-based code branches can't do any harm.

if a non sandboxes application tries to create a copy

When I run an installer from an iso with 1,000s of files on it, I won't know if this includes one of the various whitelisted executable names, and no "copying" is involved.

Feel free to close.