Shattering

Window Shattering seems to be an instance of this problem. I learned about this problem thru this interesting note. Microsoft’s reply (look for “5 Aug 2002”) seems to be to the effect that any conceivable architecture would have this property and it is thus not a security problem. They “recommended against interactive services” which in this context means that a program with great authority should not interact with the user. What about the program I use to sign documents? Am I not to see the documents I sign? They go on to say “It is the implementer of a program that decides what messages to handle and how to handle them.”. Indeed, but such programs need to know the origin of the request. A person in charge of an ICBM needs to know the origin of a launch command. The SSN of the person composing the request is not suitable for this.

The precursor to the problem is described in this note but in terms of much Windows programming jargon. Here I guess a few things about Windows. (A bit of Hermeneutics). Please correct me if I am wrong (norm at cap-lore dot com).

A service is a trusted program with dangerous authority that runs much as an application.
GDI is a specific body of code that makes various graphical output devices polymorphic. GDI runs in the kernel on recent versions of Windows.
“GDI window handles are not process specific” means that an application that can control one window can control any window if it can guess its handle which isn’t hard. (A handle is an unprotected name.)
A “window” in the context of the note, is a “system object”.
The “window procedure associated with the window directly” is whatever application code (or “code running as an application”) put up the window. This is the code that responds to events from the mouse or keyboard, via the window logic, and thence to the “window procedure” responsible for the window.
The messages that the window procedure must be designed to receive, interpret and act upon are mainly from trusted window logic code. But any holder of the handle to the window can also send such messages and indeed this ability is relied upon for some legitimate purposes. The window procedure must therefore assume that hostile messages will arrive—messages that may overwrite buffers, for instance.
Several services from Microsoft, have indeed been found to be vulnerable in this way—vulnerable in that they had unbounded buffers in which to receive messages allowing senders to deliver code to be obeyed with the recipient’s authority. The first was the Still Image Service which Microsoft patched. Such services are still at risk of abusing their authority when a correctly formatted yet hostile message arrives.
There is yet another problem: These messages are delivered to the receiving program with no indication of the source. A correctly formatted request to take some security relevant action must seemingly be obeyed even though it comes from a rogue. In a capability system received messages are known to have been sent by some program with legitimate authority to send such messages. This greatly reduces the paranoia and cost necessary to interpret most messages.
Window Shattering was inspired by the DDE server. Microsoft thereafter fixed a bug wherein the message acted upon the service without the logic of the service being able to first examining the message—the message called for execution of a routine in the recipient’s space at an address specified by the sender.
Quote:
... the Win32 API has a friendly little function called PostThreadMessage(). Enumerating processes is not a privileged operation, so you can get a PID for a localsystem [sysadmin] process with no problems. The ToolHelp functions allow you to also enumerate the threads for that process ... So, you have a list of all threads running as LocalSystem on the machine. PostThreadMessage will send any message you like to any thread you like, assuming that thread has implemented a message queue. No, you don't have to call OpenProcess(). No, there are no privileges involved.