In the latest update, several significant features and improvements have been introduced. Notably, a new SbieIni option allows users to modify password-protected configurations with improved security features. The New Box Wizard now includes a "PromptForInternetAccess" checkbox, and options to hide non-system processes and Sandboxie processes from sandboxed process lists have been added. Additionally, a mechanism to block unsafe calls via RPC Port message filtering and a template to prevent sandboxed processes from accessing system information through WMI are now available. The update also introduces options in the box creation wizard to block local network connections, hide firmware information. A new "Job Object" Options page consolidates all job object related options. Several critical fixes have been implemented, including resolving security issues with the "UseCreateToken=y" mechanism, issues with exporting sandboxes, Chrome printing problems, and various bugs affecting sandbox properties and program launching. Compatibility with Steam running sandboxed has also been improved. This release note is brought to you by Chat GPT. Download: https://github.com/sandboxie-plus/Sandboxie/releases/tag/v1.14.2 Added added SbieIni option to modify password-protected configs #3903 usage: set|append|insert|delete [/passwd:********] note: use /passwd without the password to have SbieIni prompot for the password on the console, this hides the password from view and from bing captured with the command line added checkbox for "PromptForInternetAccess" option to the New Box Wizard added option "HideNonSystemProcesses" to hide processes not in a sandbox from processes lists for sandboxed processes. added option "HideSbieProcesses" to hide Sandboxie Work Process(SbieSvc,SandboxieRpcSs,etc.). added option "HideFirmwareInfo" when it is set, the programs that try getting fireware information will get false data from HKEY_CURRENT_USER\SOFTWARE\SandboxieHide\FalseFirmwareValue added template "BlockAccessWMI" to prevent sandboxed processes from accessing system information through WMI. added template "BlockLocalConnect" to prevent sandboxed processes from sending network packs to localhost to breakout sandbox. added new option "AllowCoverTaskbar" for #3975 added RPC Port message filter mechanism to block unsafe RDP calls via the driver #3930 Usage: "RpcPortFilter=Port,ID,Label" label is optional added "Job Object" Options page to colelct all job object related options Changed Extend "Temp Template" to make it could delete local template section. Fixed fixed security issue with the newly introduced experimental "UseCreateToken=y" mechanism fixed issue with "UseCreateToken=y" when using a MSFT online account fixed Export sandbox not containing hidden files #3980 (thanks L4cache) fixed Chrome stopped printing #3926 Sandboxie will add CustomChromiumFlags=--disable-features=PrintCompositorLPAC to chrome based browsers command line Note: Less Privileged App Container (LPAC) don't work with sandboxie currently fixed Problem accessing a relative symlink with a target that starts with a dot #3981 fixed Bug - Can't open a sandbox's properties window via double-click in System Tray context window #3861 fixed Delay in launching forced programs after version 1.12.9 #3868 this issue was introdiced in 1.13.0 and may have broadly affected other usecases and cause variosue problems fixed issue with Misc Options list improved compatibility with steam running sandboxed
Thank you for this release v1.14.2 Up and running in portable mode on Win7SP1x64 The new template `BlockAccessWMI` fixed my issue with supermium browser described here: https://www.wilderssecurity.com/threads/supermium-browser-issue-in-sandboxie.453223/
Sorry for having to report unspecific yet total crashes of my main browser Opera with increased frequency using the new Sbie-Preview-versions after v1.14.0. To make things worse I cannot give any specific hints about how to reproduce those crashes for the time being. There will be no error-messages popping up, Opera will just crash totally. Sometimes the Sandbox (default) will not be cleared after the crash as it should (via autodelete) and some of its contents would rather have to be deleted manually in the aftermath. Furthermore I've got the vague impression that such sudden crashes will primarily occur on picture-rich-sites like image-download-locations - but then I've observed some of those on simple sites as well, even on my news-homepage right after browser-start-up on rare occasions. I haven't reported these faults earlier because I had hoped being able to report specific circumstances under which these crashes would occur but now I think it's about time to report about those issues even without being able to name any specifics - just to see if other users would have run into similar incidents with Sbie v1.14.1 and v1.14.2.
so 1.14.0 is fine and only the later one have issues? Could you please test 1.14.0 with the sbiedll.dll from 1.14.1 if the issue is with the dll, then sbiesvc.exe and last sbiedrv.sys to pinpoint the issues the issue seams also with firefox: https://github.com/sandboxie-plus/Sandboxie/issues/4012
please test if when 1.14.1 is installed, replacing the sbiedrv.sys with the one from 1.14.0 fixes the issue for you
I have posted on github a unsigned driver for testing if anyone with the chrome issue could please test it, and let me know if that solves the issue
It will hopefully fix the issues with browsers reported in 1.14.1 and 1.14.2 you need to have your windows in test signign mode to accept an unsigned driver then you stop sandboxie service and driver, replace the installed file with the test file, and restart sandboxie
Even though i have killed everything with SB-Plus according to task manager, when trying to replace the driver i can not because it says it is in use.
First testing observations so far: went back to v1.14.0 again and only replaced the dll with the newer version of v1.14.1 --> no crashes so far - but the jury is stil out on this question. Still too early to tell. Next I also tried to replace the service.exe with the upgraded v1.14.1-version. After that Sbie would never start up successfully, only producing countless error-messages of the same kind: Needless to say that I never proceeded onward replacing the driver, too, as Sbie would refuse to run with the altered service alone. So I'm now further observing v1.14.0 with only the dll upgraded to its v1.14.1-version. Should any crashes occur I'll report back.
the service needs replacing SbieSvc.sig as well. Please replace only the driver and test that scenario.
Now testing with also the driver upgraded to v1.14.1-version. No initial crashes observed so far - but way too early to tell. Or did you mean replacing the driver with that very latest trial-version just published on GitHub?
Ok, so, first crash with the updated sys-driver to v1.14.1 has occurred. Simply when trying to connect to my FRITZ!Box. So I suggest I'll return to v1.14.0 again and only will upgrade the dll this time to observe for an extended period of time if any crashes might occur with only the dll upgraded as well in the long run. But as it looks now the sys-driver might be the culprit.
Based on the reports on github it is quite certain that it is the driver, in 1.14.3 the breaking change will be rolled back
Two questions in that regard: 1. Does that mean that the "breaking change" has already been identified? 2. For what purpose has that "breaking change" been implemented in vs.>1.14.0 in the first place?
I'm late reporting this but I see others have. Chrome is constantly crashing, laggy and pages unresponsive with the latest update(s) of SBIE. Running not sandboxed solves the issues so far. I use the 5.69.2 classic version on latest 22H2 Win 10 and the latest Chrome release. ETA: I went to github and overwrote with an older version (5.68.5 or 1.13.5 for the +) and it works fine. Speed is back to normal and no crashing or unresponsive pages.