Block Process Access

[wraithdu]

Then you're covered.

[wraithdu]

Added the hex code of the message that was allowed by SendMessageA/W to the debug output.

[Mark_]

NtQuerySystemInformation --> you block class 5 (SystemProcessInformation) which allows to enum processes, but you allow class 49 (SystemSessionInformation) which contains the same data...

Code: Select all

typedef struct _SYSTEM_SESSION_PROCESS_INFORMATION
{
	ULONG SessionId;
	ULONG SizeOfBuf;
	PVOID Buffer; // <-- same data as SystemProcessInformation
} SYSTEM_SESSION_PROCESS_INFORMATION, *PSYSTEM_SESSION_PROCESS_INFORMATION;

and why do you block NtReadVirtualMemory but not NtWriteVirtualMemory? (used by writeprocessmemory)

ps: to remove msvcrtXXX.dll dependency:

Configuration Properties->C/C++->Code Generation
Runtime Library: switch from 'Multi-threaded DLL' to 'Multi-threaded'

[wraithdu]

WriteProcessMemory is blocked by Sandboxie...I'm not duplicating functionality here.

Changing to Multi-threaded needlessly bloats the size of the DLL, so no. There's plenty of other stuff that needs the runtimes, so you might as well install them.

SystemSessionInformation is an undocumented class (of course...) so I was unaware of it. I'll add it for the next version. Thanks for bringing it to my attention.

PS - how did you know what class I was blocking?

[AlexG]

I've just installed your DLL (InjectDll=C:\Programas\sbiextra\sbiextra.dll) to all of my 6 sandboxies and it's working just as expected in all of them.
I've tested injtest.exe with and without the DLL and it's working as expected with Sandboxie 3.43.01.
Very nice work indeed. Now my sandboxed programs are even more limited in what they can do (and steal from other running non-sandboxed programs) and i'm a little more secure
Continue with the good work.
Alex.

[wraithdu]

Added an additional class to block in NtQuerySystemInformation (thanks Mark_).

[wraithdu]

I've just installed your DLL (InjectDll=C:\Programas\sbiextra\sbiextra.dll) to all of my 6 sandboxies and it's working just as expected in all of them.
I've tested injtest.exe with and without the DLL and it's working as expected with Sandboxie 3.43.01.
Very nice work indeed. Now my sandboxed programs are even more limited in what they can do (and steal from other running non-sandboxed programs) and i'm a little more secure
Continue with the good work.
Alex.

Woohoo! Thanks

[Mark_]

WriteProcessMemory is blocked by Sandboxie...I'm not duplicating functionality here.

Changing to Multi-threaded needlessly bloats the size of the DLL, so no. There's plenty of other stuff that needs the runtimes, so you might as well install them.

SystemSessionInformation is an undocumented class (of course...) so I was unaware of it. I'll add it for the next version. Thanks for bringing it to my attention.

PS - how did you know what class I was blocking?

ah, i must have forgotten about sbie blocking wpm,
and the dll does get a bit bigger, but asking the people to install a runtime is more bloat if u ask me (i already have it tho, came with visual studio)
about the class: i reversed the dll a little bit

createtoolhelp32snapshot --> you check for TH32CS_INHERIT like this: dwFlags != TH32CS_INHERIT; but please keep in mind that there can be multiple flags set, as it is a bitflag not an enum or something, so check like this:

if( !(dwFlags & TH32CS_INHERIT) )

[Buster]

about the class: i reversed the dll a little bit

What do you use? IDA?

[Mark_]

about the class: i reversed the dll a little bit

What do you use? IDA?

and ollydbg

[wraithdu]

createtoolhelp32snapshot --> you check for TH32CS_INHERIT like this: dwFlags != TH32CS_INHERIT; but please keep in mind that there can be multiple flags set, as it is a bitflag not an enum or something, so check like this:

if( !(dwFlags & TH32CS_INHERIT) )

Not exactly. I remove the TH32CS_SNAPPROCESS and TH32CS_SNAPTHREAD bit flags first. Then if dwFlags == 0 or dwFlags == TH32CS_INHERIT (individual flags only), the call is blocked. Otherwise I test for sandboxing and conditionally allow or block.

[Mark_]

Not exactly. I remove the TH32CS_SNAPPROCESS and TH32CS_SNAPTHREAD bit flags first. Then if dwFlags == 0 or dwFlags == TH32CS_INHERIT (individual flags only), the call is blocked. Otherwise I test for sandboxing and conditionally allow or block.

are you sure?
might be that the compiler is optimizing it out somehow:

Code: Select all

100019E9   > \8B7C24 10     mov     edi, dword ptr ss:[esp+10]
100019ED   .  85FF          test    edi, edi
100019EF   .  74 4A         je      short sbiextra.10001A3B
100019F1   .  81FF 00000080 cmp     edi, 80000000
100019F7   .  74 42         je      short sbiextra.10001A3B

and if you want to do it like that, you would also have to remove SNAPMODULE and SNAPHEAPLIST

[wraithdu]

Yes, I'm sure. It's actually written as if ((dwFlags != 0) && (dwFlags != TH32CS_INHERIT)) then test.

Also, SNAPMODULE and SNAPHEAPLIST are process specific, so those calls are allowed if the target process is the current process or a child or running in the same sandbox.

[knotme]

XP pro SP3
Using sdelete in all configurations


sbiextra v1.0.0.14

When using add-on MinimizeToTray v1.5 in Firefox it crashes the browser when trying to minimize into the icon on taskbar and creates two icons. I do not know if there is a work around for this or the extension is not compatible.

https://addons.mozilla.org/en-US/firefox/addon/10488

By the way thanks for the efforts.

[wraithdu]

I've warned that features of this DLL can / will break other stuff. I'm only guessing wildly, but that extension probably has to interact with explorer in some way. Since explorer is outside the sandbox, this is likely blocked. The crash is probably due to bad coding in the extension which is not handling internal errors / failures properly.

You can try to find out which feature of my DLL is causing the problem by selectively turning them off via the INI file. Perhaps you can do without that particular protection.