Sticky Password possible sandbox breach [SOLVED]

[henryg]

After an update to SP to 8.12.0.127 and possibly to the addin today, SP suddenly works in sandboxed Firefox and Chrome even though the program is loaded outside. This is a change in behaviour as previusly SP had to be launched into the sandbox, and BEFORE I changed security.sandbox.content.level to 2!

An SP template is in use, again unchanged:

Code: Select all

Tmpl.Title=Sticky Password
Tmpl.Class=Security
Tmpl.Url=http://www.stickypassword.com/
Tmpl.Scan=s
Tmpl.ScanKey=\REGISTRY\MACHINE\SOFTWARE\Lamantine\Sticky Password
Tmpl.ScanProduct=Sticky Password_is1
OpenIpcPath=*\BaseNamedObjects*\Mutex*Process*API*
OpenIpcPath=*\BaseNamedObjects*\NamedBuffer*Process*API*
OpenIpcPath=*\BaseNamedObjects*\AutoUnhookMap*
OpenIpcPath=*\BaseNamedObjects*\mchLLEW2*
OpenIpcPath=*\BaseNamedObjects*\mchMixCache*
OpenIpcPath=*\BaseNamedObjects*\PCActivityHookInfo:*
OpenIpcPath=*\BaseNamedObjects*\spAutofillInfo:*
OpenIpcPath=*\BaseNamedObjects*\spCaptionButtonInfo:*
OpenIpcPath=*\BaseNamedObjects*\TtsMappedObject_Tts*
OpenIpcPath=*\BaseNamedObjects*\{CEA68AE7-EF0E-4AD5-9BAF-38DB1A30EF56-*
OpenIpcPath=*\BaseNamedObjects*\spPasswordAssistantClosedEvent:*
OpenWinClass=$:stpass.exe
NoRenameWinClass=Internet Explorer_Server

It is convenient in many respects, but shouldn't be happening.

Windows 10 x64 v1703 build 15063.540; Sandboxie 5.21-2; Firefox 56.0b6 64 bit, AVG Internet Security 16.151.8013; MBAE 1.10.1.24

[Barb@Invincea]

Hello henryg,

What has changed, exactly? The template should allow SP to work with Sandboxie, that's what they are for. They typically involve punching holes in the Sandbox (which do not post a serious security risk) in order to allow communication between the apps.

Also, please test the behavior in a new Sandbox with default settings. If the problem persists, post your Sandbox configuration file so that I can have a look. (Configure--> Edit Configuration . Copy and paste the contents here, please use the "</>" button to format it).

Regards,
Barb.-

[henryg]

Nothing happened other than the update of SP to ...127 causes a sandbox leak. I made no other changes either to SB or SP other than to update SP; the template is unchanged, I posted it just for info.

I'll pm my ini file to you.

Regards


Henry

[Barb@Invincea]

Hi henryg,

What do you mean by "leak"? What has changed when it comes to the SP behavior (exactly)?
Can you please provide an example?

Also, does it stop if you remove the template? (As explained, templates do open holes to allow communication to happen).

I will review your .ini file soon and update this thread if anything new comes up.

Regards,
Barb.-

[henryg]

Hi henryg,

What do you mean by "leak"? What has changed when it comes to the SP behavior (exactly)?
Can you please provide an example?

"Leak" ie my browsers have access to a non-sandboxed program which should not be the case. Leak/breach/hole/vulnerability - you can choose whatever term you prefer.

Also, does it stop if you remove the template? (As explained, templates do open holes to allow communication to happen)

I'll try this when I can

I will review your .ini file soon and update this thread if anything new comes up.

Ta

[Barb@Invincea]

Hello henryg,

A leak/vulnerability, etc...would exist if a Sandboxed application escaped the Sandbox and modified your host in any way. I am asking for a specific example of what are you seeing and how to reproduce it, so that I can test it.

I have reviewed your configuration and it looks like you are using a template, plus the following entries:
OpenFilePath=spuiamanager.exe,%Personal%\OneDrive\Sync\default.spdb
OpenFilePath=spuiamanager.exe,%Personal%\SP\default.spdb
OpenFilePath=stpass.exe,%Personal%\OneDrive\Sync\default.spdb
OpenFilePath=stpass.exe,%Personal%\SP\default.spdb

You hare explicitly opening paths for StickyPassword to modify your host.

Regards,
Barb.-

[henryg]

I will look at the enries you refer to, but I have already given you specifics of what is happening and how, and so you should be able to reproduce it. So I have no idea what else you want.

And those entries have been there for a long time (and I would not and do not have the knowledge to put them there without advice/a template - probably from Sandboxie staff at the time), so something else has to be the immediate cause for the change in behaviour - see last para. [Edit] disablingthem makes no difference.

Why does referring to a possible leak/breach always cause such a response in these forums from staff? Even when there is no suggestion that it is Sandboxie's fault - just talking about an effect. This has been the case for many years here, and it is about time Sandboxie staff "get over it" IMO!

Anyway, the "culprit" looks to be a program, spNMHost.exe that is now starting with Firefox automatically and which I have not seen before, so I assume it is loaded by the latest Sticky Password addin. Teminate the program, and access tto SP loaded outside the sandbox stops. Maybe the template/the enties you refer to now need changing to deal with the program.

[Barb@Invincea]

Hello henryg,

A leak/vulnerability is an important issue, so in order for us to verify it, we may ask as many questions and clarification as needed to ensure everything is covered and critical steps are not missed (thus why I asked for the exact repro steps).

A leak involves a program escaping the Sandbox and modifying the host. What is leaking outside the Sandbox in this scenario?

If you want to use Sticky Password sandboxed only, you can close it from the tray and launch it via a sandboxed browser.
If you have the paid version of Sandboxie, you can add it to your force programs, or just remove it from your Windows Startup and then manually launch it from a Sandboxed browser, as suggested before.

Regards,
Barb.-

[henryg]

We have different views of what constitues a breach/leak or whatever you would prefer to call it, but its not something I feel should be a problem. Let's ignore the semantics.

So the question now is, why does spNMHost.exe allow a sandboxed Firefox or Chrome to be able to access the main Sticky Password program and its database when loaded only outside the sandbox; given that no other changes were made to Sandboxie or its settings other than the update to SP. And how do I block it, yet allow SP to work properly when loaded in a sandbox. Simple issue, maybe not so simple solution.

Given I have now disabled all OpenFilePath=spuiamanager.exe... entries in Sandboxie.ini I assume the template is the cause, but I do not have the knowledge to work it out.

SP remains forced in my Sandboxie setup, so it is only an (potential) issue if I have made it load outside a sandbox for some reason, but which I need to do from time to time.

[Syrinx]

And how do I block it, yet allow SP to work properly when loaded in a sandbox. Simple issue, maybe not so simple solution.

It depends what you mean by 'work properly'. If you want to prevent local changes to the database while it runs inside Sandboxie but still be able to load and use the existing passwords that is possible by simply disabling the template for Sticky Password under Software Compatibility and removing the lines that were added for the .spdb.

I tested this in a VM and even while I had an instance of Sticky Password logged in outside Sandboxie the addon was forced to load a new instance inside Sandboxie (along with requesting the master password) in order to auto-fill a login form. Obviously with this setup you won't be able to update it easily from within the box. Also if the account were to be set up with cloud storage (eg premium) I can't say for sure how that would work out but it'd likely result in the cloud version being updated and filtering over to the non-sandboxed one when you add logins from inside. Also note that the recovery dialog (if enabled) should pop up with options to save the spdb database when it is changed such as adding a login (at least it did in my quick test). Hope that helps.

[henryg]

Thanks Syrinx

Unusually for me, I want the database to be accessed and updated when sandboxed, but that's only locally as I don't use the cloud to store the file.

I'll play with the template a bit, but all in all I think I'll continue to rely on forcing the program to load sanboxed. If I need to run it outside the sandbox, I'll just have to accept the responsilibilty to shut it down when finished. Not ideal but not so bad.

[Syrinx]

OK that should be fairly simple then, you'd just need to open up the path the database is located at for writing outside the box and disable the template.
For me this worked in a quick test, OpenFilePath=stpass,%UserProfile%\Sticky Passwords\*.spdb*
It seems to keep a journal and backups as well but you could technically just allow the default.spdb instead of *.spdb*

Tested with Sticky Password 8.0.12.127

[henryg]

If I give access to the database via an openfilepath, does that mean I shouldn't need the SP Template at all? Being a bit lazy here as I will try disabling it anyway; and ISTR at some point previously it worked fine without anyway.

Thanks again for the help.

[Syrinx]

Guess I should have copy and pasted it when I tested. I forgot the .exe in the other post.

Code: Select all

OpenFilePath=stpass.exe,%UserProfile%\Sticky Passwords\*.spdb*

[Syrinx]

Wanted to edit my last post but couldn't as it timed out I suppose.

This bugged me so I ended up re-testing and sure enough that still wasn't right.
Here is the (hopefully correct) corrected path /sigh
Copy and pasted directly from the VMs ini this time. Sorry about that but it happens on occasion when I'm in full drunk mode.

Code: Select all

OpenFilePath=stpass.exe,%UserProfile%\My Documents\Sticky Passwords\*.spdb*

If I give access to the database via an openfilepath, does that mean I shouldn't need the SP Template at all?

The template is basically designed to allow a sandboxed program, eg firefox, chrome etc to communicate with a non-sandboxed (or perhaps cross sandbox) Sticky Passwords instance. This seems to be the exact opposite of what you want so you will likely want to keep it disabled.