Re: More on Shatter

["Daniel Newby" <dnewby () nomadics com>]

At 11:52 AM 8/23/2002 +0100, Chris Paget wrote:
> Folks,
>
> I've written a followup paper on Shatter which contains a few
> corrections, some new techniques, and an FAQ.  It's available at
> http://security.tombom.co.uk/moreshatter.html

I don't understand why filtering cannot fix the problem with WM_TIMER.  By 
definition, the offending lParam parameter of the WM_TIMER message is 
"Pointer to an application-defined callback function that was passed to the 
SetTimer function when the timer was installed."[1]  I am not a Win32 
programmer, but it would seem trivial for the system to check lParam for 
arriving messages against the callbacks previously registered using 
SetTimer.  If it didn't match, the message could be discarded (and logged 
as an attempted access control violation).  If it did match, the 
application would receive an unexpected call to a function under its 
control.  That is not perfect, but it's a vast improvement over being able 
to call arbitrary memory locations.

Furthermore, why does any process ever need to receive a WM_TIMER message 
from a non-system, non-self process?  Would any important applications 
break if all WM_TIMER messages from uncontrolled sources were 
blocked?  Similar arguments hold for other message types.

[1]  Documentation on MSDN:  http://msdn.microsoft.com/library/
default.asp?url=/library/en-us/winui/winui/windowsuserinterface/
windowing/timers/timerreference/timermessages/wm_timer.asp
(URL needs pasting back together.)