MessageBox with MB_DEFAULT_DESKTOP_ONLY or MB_SERVICE_NOTIFICATION can not display title and text correctly in security hardened box.

[nemuri-cat]

Describe what you noticed and did

Hello!

When I use some applications in Sandboxie, I observe that some message boxes do not show properly. After digging the source codes of these apps, I found it is a common issue:

In the security-hardened box, any MessageBox with MB_DEFAULT_DESKTOP_ONLY/MB_SERVICE_NOTIFICATION will not show the title and text correctly.

Here is the example code (Compiled in MSVC 2022):

#include <Windows.h>

int main(int argc, char const* argv[]) {

	// Sleep for time switching to any other window 
	Sleep(3000);
	MessageBoxA(NULL, "Hello World", "This is the title",
		MB_ICONINFORMATION |
		MB_DEFAULT_DESKTOP_ONLY // Or: MB_SERVICE_NOTIFICATION
	);
	return 0;
}

I can't find where to upload the compiled binary. But with any compile option, it seems the issue will still occur.
Or use the following command to compile a reproducible binary:

@REM in Developer Command Prompt for VS 2022. Save the code to the file: `main.c`
cl.exe /c /Od main.c && link /OUT:main.exe /nologo /ENTRY:main /SUBSYSTEM:WINDOWS main.obj kernel32.lib user32.lib

also C# code:

using System.Windows;
using System.Threading;

namespace TestApp {
    class App {
        public static void Main(string[] args) {
            
            // Sleep for time switching to any other window 
            Thread.Sleep(3000);
            MessageBox.Show("Hello World!", "This is the title",
                MessageBoxButton.OK, MessageBoxImage.Information, MessageBoxResult.OK
                , MessageBoxOptions.DefaultDesktopOnly
            );
        }
    }
}

Steps to Reproduce:

1. Create a new security-hardened box.
2. run application compiled from above codes in sandbox just created.

When running without sandboxied:

When running in a security-hardened box:

Any box with the option UseSecurityMode=y or SysCallLockDown=y will be affected.

According to Microsoft docs, this option shows a messagebox in front of any window.
But the executable compiled from the above code still shows the messagebox on top of every window in security hardened box, just leaving the text empty. So I think it is not a security feature but a compatibility issue.

I tested all major sandboxie versions in a virtual machine with a clean installation, it seems this issue exists from an early version (Since Sandboxie Plus 1.3.1 64-bit).

How often did you encounter it so far?

No response

Affected program

Any program with MessageBox using MB_DEFAULT_DESKTOP_ONLY/MB_SERVICE_NOTIFICATION

Download link

Not relevant

Where is the program located?

The program is installed both inside and outside the sandbox.

Expected behavior

Show the messagebox title and text correctly.

What is your Windows edition and version?

Windows 10 Pro 21H2 64-bit

In which Windows account you have this problem?

A local account (Standard user).

Please mention any installed security software

Microsoft Defender Antivirus

What version of Sandboxie are you running?

Sandboxie Plus 1.12.5 64-bit

Is it a new installation of Sandboxie?

I recently did a new clean installation.

Is it a regression?

Since Sandboxie Plus 1.3.1 64-bit (Test in VM)

In which sandbox type you have this problem?

In a standard isolation sandbox (yellow sandbox icon).

Can you reproduce this problem on a new empty sandbox?

I can confirm it also on a new empty sandbox.

Did you previously enable some security policy settings outside Sandboxie?

No response

Crash dump

No response

Trace log

No response

Sandboxie.ini configuration

No response

[offhub]

Add the ApproveWinNtSysCall setting to [GlobalSettings] and then try after reloading the config. ****

Sandboxie-Plus > Options > Global Settings > Edit ini Section > OK
Sandboxie-Plus > Options > Reload configuration

ApproveWinNtSysCall=RaiseHardError

[nemuri-cat]

ApproveWinNtSysCall=RaiseHardError

Thank you for your reply! This option does let the application work.
However, it is a global option and may break the security of all other Sandboxes.
This syscall can cause BSOD or be used by some viruses according to some searches.

After some surveys, I found that MB_SERVICE_NOTIFICATION does call NTRaiseHardError at a low level.
I wrote a code to call NtRaiseHardError directly and got the same result: the message box was shown but no text in security hardened box.

#include <Windows.h>

#define STATUS_SERVICE_NOTIFICATION 0x40000018L
#define HARDERROR_OVERRIDE_ERRORMODE 0x10000000L

typedef struct _UNICODE_STRING {
	USHORT Length;
	USHORT MaximumLength;
	PWSTR  Buffer;
} UNICODE_STRING, * PUNICODE_STRING;

typedef NTSTATUS(NTAPI* RtlInitUnicodeString_t)(
	PUNICODE_STRING dst_str,
	PCWSTR src_str
	);

typedef NTSTATUS(NTAPI* NtRaiseHardError_t)(
	NTSTATUS ErrorStatus,
	ULONG NumberOfParameters,
	ULONG UnicodeStringParameterMask,
	PULONG_PTR Parameters,
	ULONG ValidResponseOption,
	PULONG Response
	);

int main(int argc, char const* argv[]) {
	HMODULE hNtdll = GetModuleHandleA("ntdll.dll");

	if (hNtdll != 0) {

		ULONG_PTR params[4];

		ULONG ulResponse;
		UNICODE_STRING Text, Caption;

		NtRaiseHardError_t NtRaiseHardError = (NtRaiseHardError_t)GetProcAddress(hNtdll, "NtRaiseHardError");
		RtlInitUnicodeString_t RtlInitUnicodeString = (RtlInitUnicodeString_t)GetProcAddress(hNtdll, "RtlInitUnicodeString");

		RtlInitUnicodeString(&Text, TEXT("Hello World!"));
		RtlInitUnicodeString(&Caption, TEXT("Test"));

		params[0] = (ULONG_PTR)&Text;
		params[1] = (ULONG_PTR)&Caption;
		params[2] = (ULONG_PTR)MB_OKCANCEL;
		params[3] = (ULONG_PTR)0;

		NtRaiseHardError(
			STATUS_SERVICE_NOTIFICATION | HARDERROR_OVERRIDE_ERRORMODE,
			4,
			3,
			params,
			1,
			&ulResponse
		);
	}
}

As the message box does prompt on the top without ApproveWinNtSysCall=RaiseHardError, I think this syscall might be successfully invoked without this option (maybe as a hooked version), and there might be some problems during the hooking.

[DavidXanatos]

I don't think ApproveWinNtSysCall=RaiseHardError is particularly risky, its a syscall to crash the application using it, and if we are worried about windows kernel bugs then this syscall even without the full access token will be just as problematic