Windows PostThreadMessage() Arbitrary Process Killing Vulnerability

SecurityFocus has a report of a new vulnerability which can cause any process in Microsoft Windows to be killed with a specially crafted message, due to a design flaw in PostThreadMessage(). There is even an exploit showing how this could be done.

What is scarey about this is the fact that if the reports are true a running process that has a message queue and is sent one of 3 different messages, the process may terminate. This termination will occur despite any security level differences between processes, as well as any safe guards to prevent this behaviour, such as requiring a password before the process is killed.

I've seen something similar to this before in something Mark wrote at SysInternals. But this is one of those things that is so trival to exploit, but so hard to fix. Not sure what to make of it.

One thing that never made sense to me is the lack of information on message processing based on privilege. Try it yourself. As a normal user, use runas to run something with Administrative privileges that requires UI updates. I use explorer.exe as an example. Right click in a folder and create a new file. You won't see the file, or be able to "edit" the name.

When an update message is called, it gets gobbled. So in many cases, you have to manually get the app to refresh (F5) to see any changes. For some reason it supressed the messages. So why wouldn't the message processing between security contexts be able to do the same thing to reject a WM_QUIT message from a lower process? Seems silly if you ask me.