WM_DESTROY crashes cfp?

Learn about Computer Security Leak Testing/Attacks/Vulnerability Research
1

I just thought this may be interesting - cfp.exe crashes if you open the GUI and post a WM_DESTROY message to the GUI window. To test this get the unstable Process Hacker build from https://www.ohloh.net/p/processhacker/packages, open the CIS GUI, right-click on cfp.exe in Process Hacker, select Terminator, and double-click the W1 test. You will get a prompt from CIS about a window message being sent, and allow the action. cfp.exe will crash shortly. And no, Process Hacker doesn’t use its driver for this.

I know this requires you to allow the action, but it seems odd that while CIS blocks every other termination method out there without prompting the user, CIS prompts you and then crashes on this one. You will see that the WM_QUIT message (W2 test in PH) is handled without any prompts.

2

I’ll see if i can test this later on…

Maybe the W2 test doesn’t prompt for a “message” because of this ?

Note: WM_QUIT is not a real message. PostQuitMessage sets a flag on the message queue to indicate that a quit is pending.
3

Microsoft lies a lot, especially with things to do with Win32. PH posts both the WM_DESTROY and WM_QUIT messages using PostMessage. With the help of a disassembler you can see that neither user32!PostMessage nor win32k!NtUserPostMessage (and its helper routines) treat WM_QUIT as anything special. CIS hooks NtUserPostMessage (amongst other things) in order to prevent window-based attacks.

win32k!xxxInternalGetMessage does treat WM_QUIT with a special case - it returns FALSE, so user32!GetMessage will return 0 and in most message loops the application will exit. Bottom line: WM_QUIT is a real message. Microsoft is lying.

EDIT: Well, here’s the actual function in cmdguard.sys. You can see which window messages are blocked by CIS:

BOOLEAN CgIsMessageBad(UINT Msg)
{
    return
        Msg == WM_CLOSE || 
        Msg == WM_QUIT || 
        Msg == WM_SETTEXT || 
        Msg == WM_GETTEXT || 
        Msg == WM_SETHOTKEY || 
        Msg == WM_GETHOTKEY || 
        Msg == WM_CONTEXTMENU || 
        Msg == WM_NCDESTROY || 
        Msg == WM_MDIDESTROY || 
        Msg == WM_QUERYENDSESSION || 
        Msg == WM_QUERYOPEN || 
        Msg == WM_WININICHANGE || 
        Msg == WM_ENDSESSION || 
        Msg == WM_WTSSESSION_CHANGE || 
        Msg == WM_DESTROYCLIPBOARD || 
        Msg == WM_DESTROY || /* WM_DESTROY should be blocked! */
        ...
}

Maybe the WM_DESTROY message is being sent to some hidden GUI window which isn’t protected by cmdguard?

4

COMODO Internet Security group has a protection setting with Windows Message protection disabled. This should be the reason the message is not silently blocked though CIS will nevertheless trigger alerts for any type of message sent to its GUI for protection purposes.

Changing the default policy to enable protection for Windows message (Protection settings) and adding explorer.exe, Windows System applications and Comodo Internet Security in win message exceptions should block automatically those messages for the rest of the applications.

The explorer.exe exception is meant to enable the double click on the tray icon whereas the other exceptions might not be necessary but I didn’t test for that possibility.

5

You can verify experimentally that what you said is incorrect. I have already cited the WM_QUIT message which is blocked without any prompts. You can try other messages as well, and they will be blocked silently.

Changing the default policy to enable protection for Windows message (Protection settings) and adding explorer.exe, Windows System applications and Comodo Internet Security in win message exceptions should block automatically those messages for the rest of the applications.

That’s not what I’m talking about, though. It has nothing to do with CIS policies, because it seems that CIS gets special protection, different to the “Process Termination” protection setting.

The explorer.exe exception is meant to enable the double click on the tray icon whereas the other exceptions might not be necessary but I didn't test for that possibility.

Again, that has nothing to do with it. You can see the list of blocked messages in the code I posted, and I’m pretty sure CIS doesn’t support process-process settings (e.g. explorer.exe is allowed to perform a specific action on a specific process).

6

Guess I wasn’t able to get your point by reading your comments but indeed it looks like CIS gets special protection and thus an alert is displayed for nearly all messages including WM_DESTROY message whereas changing the configuration accordingly will silently block that message as well.

AFAIK CIS will allow some messages, block some others and trigger alerts for the rest including WM_destroy. As message are involved it looks like that Termination self protection is meant to group a subset of possible messages which ATM don’t include WM_DESTROY nevertheless enabling Winmessage protection setting can handle it without alerts as well.

I don’t know why WM_DESTROY was not added to Termination protection group but the ability to silently block it is already there and can be enabled with a policy change as I described.

7

Well for non destructive messages you would expect it to alert, for destructive one’s like WM_DESTROY that should not be the case, there is no need to hassle a user with an alert for WM_DESTROY on CIS files as far as i can see… and that’s not on a tweaked setup, it should become part of the default protection if you ask me. If there already is a list of known bad call’s then this is a nice one also if you ask me.

8

Indeed it looks like WM_DESTROY should have been included in the termination group. Though it looks like WM_DESTROY is included in the Window message group and a winmessage alert will be triggered regardless of the target application (eg notepad) or silently blocked if winmessage protection is enabled in the protection settings of the target application

AFAIK WM_DESTROY is still trapped whenever it might be unexpected to confirm it to belong to the more wide Winmessage monitor rather than Termination monitor group so the silent block outcome can be achieved using a policy change whenever a code change moving WM_DESTROY to the Termination monitor group would require no policy change in upcoming versions.

I guess the ability to silently block WM_DESTROY would be still relevant for the span of this topic whenever the title focus on CFP.exe crash due to WM_destroy and the first post on the fact that other termination messages are silently blocked by the termination monitor protection whereas WM_destroy trigger an alert.

9

Can you guys confirm the behaviour I mentioned in the first post? I would like to be proven wrong, if possible! :wink:

10

Sorry, I don’t know what I was thinking. :-[ I’ve just tested the Process Termination protection setting with notepad.exe and it appears to block every single user-mode termination method available. I swear in an earlier version CIS did have special protection, though.

Anyway, my point still remains. Why does WM_DESTROY get special treatment?

EDIT: Interesting, I’ve discovered that WM_NCDESTROY also kills CIS, this time instantly.

11

IIRC CIS should be able to trap windows message sent to is GUI even using Internet security config (which got winmessage trapping disabled), though it looks like cfp.exe crashes without triggering an alert if Winmessage is disabled whenever in that case PH apparently report WM_DESTROY as failed.

Did you carry this WM_NCDESTROY test while windows message monitoring was disabled? AFAIK it should be trapped like WM_DESTROY.

[attachment deleted by admin]

12

What do you mean by disabled? I didn’t check protection settings for the COMODO Internet Security group, but in D+ settings Window Message monitoring was on.

EDIT: OK, I enabled Window Message protection for the COMODO Internet Security group and all window messages are now blocked. The downside is that now I can’t minimize the window :(. Now I see what you were talking about.

Maybe we should have the “destructive” window messages in the Process Termination category, instead of allowing them by default?

13

Indeed grouping all destructive messages under the Termination category will provide more meaningful alerts and silently blocked according to policy protection settings defaults for COMODO Internet Security group.

Though WM_NCDESTROY should trigger an alert as well if Windows message monitoring is enabled. Also enabling Windows message protection for COMODO Internet Security group shouldn’t prevent minimize even without any exception. ???