Re: More on Shatter

From: Daniel Newby (dnewby@nomadics.com)
Date: 08/23/02 

Date: Fri, 23 Aug 2002 14:15:38 -0500
To: vuln-dev@securityfocus.com
From: "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.)