4.17 Beta Available (Latest Version 4.17.8)

[nanana1]

We are testing with Chrome Version 42.0.2311.82 beta-m. As soon as 43 is moved to beta, we will begin testing.

Thanks, Curt, that would not be long because Google has made Chrome 42.0.2311.90 stable today.

Chrome 43 beta is coming soon !

[Curt@invincea]

Perhaps a regression. I was running 4.17.1 along with a clean install of HitmanPro.Alert 3 build 181 with no errors after four days of heavy usage. Within a few hours of upgrading to 4.17.2, I see random Chrome 41.0.2272.118 m 64-bit startup errors:

Code: Select all

2015-04-14 08:04:13 SBIE2101 Object name not found: , error OpenProcess (C0000022) access = 001FFFFF
2015-04-14 08:04:13 SBIE2314 Canceling process SandboxieRpcSs.exe
2015-04-14 08:04:13 SBIE2314 Canceling process SandboxieRpcSs.exe
2015-04-14 08:04:13 SBIE2204 Cannot start sandboxed service RpcSs (1)
2015-04-14 08:04:13 SBIE2204 Cannot start sandboxed service DcomLaunch (-4)

Chrome does execute; SandboxieRpcSs.exe and SandboxieDcomLaunch.exe are running. Chrome appears to function normally. In the past, while running HitmanPro.Alert 3 release candidates, Chrome would execute with the same errors but was unresponsive (I have WinDbg output for these instances).

I see random startup errors with Thunderbird 31.6.0 as well. Thunderbird's UI never materializes but the process is running. I attached WinDbg to it and get this:

Any ideas?

Are you running Chrome with dropped rights? If not, it appears that HMPA is trying to open some process outside the sandbox.

[Peter2150]

Yes. Try adding c:\windows\cryptoguard to your direct access file list. HMPA uses that for it's cryptoguard prevention

Curt that may be needed in the HMPA template

Pete

[Curt@invincea]

Yes. Try adding c:\windows\cryptoguard to your direct access file list. HMPA uses that for it's cryptoguard prevention

Curt that may be needed in the HMPA template

Pete

Nick is going to have to try this out. That folder is empty in my test VM. But if they do stick an exe in there at some point, opening that folder is only going to allow them to start that exe in the sandbox. Sbie will not allow a sandboxed app to request write access to a process that is already running outside the sandbox.

[Curt@invincea]

VMWare HGFS (Host Guest File System) mapped drives are now supported.

Can you give more detail about that please

See this link in VMWare docs
https://pubs.vmware.com/workstation-9/i ... %2522%2520

[cornflake]

VMWare HGFS (Host Guest File System) mapped drives are now supported.

Can you give more detail about that please

See this link in VMWare docs
https://pubs.vmware.com/workstation-9/i ... %2522%2520

Thanks Curt I know about shared folders and I should've been more specific. I'm interested in the technical details, what changes were made to get Sandboxie working with hgfs. I try to block VMWare devices where I can, for example I block these:
ClosedFilePath=*Device\hcmon*
ClosedFilePath=*Device\vmci*
ClosedFilePath=*Device\vmnet*
Anyway I want to ensure nothing in the sandbox can access anything in VMWare. I am using potentially malicious software in a VM+Sandboxie. If someone has an exploit for the VMWare guest that they can send in a pipe to the host or something that's a problem. Anything I can do in Sandboxie to mitigate that I want to do. Either that or I have to turn off the guest tools which would make using them much more difficult.

So what I really want to know is did you have to give a device or api pipe direct access. Was a hole opened, etc etc... Thanks

[bjm]

With 4.17.2 do I remove the Direct Access Pipe for hmpalert now that SBIE has a Template for HMP.A

[Mr.X]

With 4.17.2 do I remove the Direct Access Pipe for hmpalert now that SBIE has a Template for HMP.A

Hi bjm, yes. That's the purpose of such template...

[Curt@invincea]

Thanks Curt I know about shared folders and I should've been more specific. I'm interested in the technical details, what changes were made to get Sandboxie working with hgfs. I try to block VMWare devices where I can, for example I block these:
ClosedFilePath=*Device\hcmon*
ClosedFilePath=*Device\vmci*
ClosedFilePath=*Device\vmnet*
Anyway I want to ensure nothing in the sandbox can access anything in VMWare. I am using potentially malicious software in a VM+Sandboxie. If someone has an exploit for the VMWare guest that they can send in a pipe to the host or something that's a problem. Anything I can do in Sandboxie to mitigate that I want to do. Either that or I have to turn off the guest tools which would make using them much more difficult.

So what I really want to know is did you have to give a device or api pipe direct access. Was a hole opened, etc etc... Thanks

HGFS file names are prefixed in the kernel with "\device\mup\;hgfs". Previously, Sbie didn't know what to do with this prefix, so any attempt to access these drives failed. Now it recognizes it, can access it, and treats it like any other mapped drive. All the open/close rules still apply. By default it is sandboxed just like a network drive. However, if you do not want sandboxed apps to even see it, now you need to close it just like you would a network drive.

[cornflake]

So what I really want to know is did you have to give a device or api pipe direct access. Was a hole opened, etc etc... Thanks

HGFS file names are prefixed in the kernel with "\device\mup\;hgfs". Previously, Sbie didn't know what to do with this prefix, so any attempt to access these drives failed. Now it recognizes it, can access it, and treats it like any other mapped drive. All the open/close rules still apply. By default it is sandboxed just like a network drive. However, if you do not want sandboxed apps to even see it, now you need to close it just like you would a network drive.

Thanks for the information. I used to block ClosedFilePath=*;* but it caused too many problems. I'll consider blocking based on the prefix you gave.
Edit: I already block ClosedFilePath=*Device\Mup\* so I guess I'm covered.

[Curt@invincea]

So what I really want to know is did you have to give a device or api pipe direct access. Was a hole opened, etc etc... Thanks

HGFS file names are prefixed in the kernel with "\device\mup\;hgfs". Previously, Sbie didn't know what to do with this prefix, so any attempt to access these drives failed. Now it recognizes it, can access it, and treats it like any other mapped drive. All the open/close rules still apply. By default it is sandboxed just like a network drive. However, if you do not want sandboxed apps to even see it, now you need to close it just like you would a network drive.

Thanks for the information. I used to block ClosedFilePath=*;* but it caused too many problems. I'll consider blocking based on the prefix you gave.
Edit: I already block ClosedFilePath=*Device\Mup\* so I guess I'm covered.

Yes, that ClosedFilePath will still block HGFS. So you don't need to change anything.

[bjm]

With 4.17.2 do I remove the Direct Access Pipe for hmpalert now that SBIE has a Template for HMP.A

Hi bjm, yes. That's the purpose of such template...

[bjm]

With 4.17.2 do I remove the Direct Access Pipe for hmpalert now that SBIE has a Template for HMP.A

Hi bjm, yes. That's the purpose of such template...

Yeah, this is my first beta build Template as I recall....so, didn't know protocol. Test beta with Pipe or test wo Pipe.
So, I'll update and remove Pipe....

[nick s]

Are you running Chrome with dropped rights? If not, it appears that HMPA is trying to open some process outside the sandbox.

I do have Drop Rights enabled for Chrome's sandbox. I've now disabled it and thus far no Chrome-related errors. Hopefully that resolves things for Chrome. After upgrading to 42.0.2311.90 m (64-bit) yesterday, I was getting at least one per hour of usage. None so far now.

Thunderbird has its own sandbox but Drop Rights has always been disabled.

As far as CryptoGuard is concerned, I have kept it disabled in HMPA's settings because it interferes with my usage of secure file wiping (I use Jetico's BCWipe).

[bjm]

What up with Sign In.....Forum is not holding my Sign In....goes Sign In after awhile ...