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.)
This archive was generated by hypermail 2b30 : Fri Aug 23 2002 - 13:18:12 PDT