Vulnerability Development mailing list archives
Re: More on Shatter
From: Dragos Ruiu <dr () kyx net>
Date: Fri, 23 Aug 2002 15:33:12 +0000
Filtering and lookups in tables can be computationally intensive tasks. And parsing every message to weed out some is not only potentially slow, but could be a cure worse than the disease... because it might break potentially sloppy code in some critical app... The added latency might be a serious issue in a time critical place like a *timer* service (or message) routine. Windows already has a bad rep as far as latency and predictability, and this kind of band-aid might exacerbate the already existing issue for some applications that try to do real-time things (as I wager most applications using timers do). Yep, this is a hard problem. The real solution is not to pass the call back in this way, but such is the curse of the pre-defined API you have to maintain backwards compatibility with. Maybe another few hundered MB of code might fix it? :-) Probably not. If it's any consolation there are some similar locked into stone API architectural issues in things like POSIX too that ought to be fixed but cannot while retaining backwards compatibility - though perhaps not of this magnitude of impact. As much as it seems easy to bash MS for this one, it isn't their fault some applications are lame :-). Though it seems to me they *should* fix the default handler for WM_TIMER in DefWindowProc() to avoid the arbitrary callback use but I don't know enough to say whether this too would break a lot of stuff since someone at MS who probably knows more about this seems to think this is a bad idea. So putting in good WM_TIMER message handlers in applications has to be added to the long list of things that a good Win32 app developer *has* to do. And checking the handler has to stay on the Q/A and pen-test engineer's checklist because we know some applications programmers won't know enough or be dilligent enough to do this. cheers, --dr On August 23, 2002 07:15 pm, Daniel Newby wrote:
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.htmlI 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.)
-- dr () kyx net pgp: http://dragos.com/kyxpgp Advance CanSecWest/03 registration available: http://cansecwest.com "The question of whether computers can think is like the question of whether submarines can swim." --Edsger Wybe Dijkstra 1930-2002
Current thread:
- More on Shatter Chris Paget (Aug 23)
- Re: More on Shatter Daniel Newby (Aug 23)
- Re: More on Shatter Dragos Ruiu (Aug 24)
- Re: More on Shatter Daniel Newby (Aug 24)
- Re: More on Shatter Dragos Ruiu (Aug 24)
- <Possible follow-ups>
- re: More on Shatter HalbaSus (Aug 25)
- Re: More on Shatter Darryl Luff (Aug 25)
- Re: More on Shatter Syzop (Aug 26)
- Re: More on Shatter H C (Aug 26)
- RE: More on Shatter Kris Kistler (Aug 26)
- RE: More on Shatter Richard Masoner (Aug 26)
- RE: More on Shatter Mark Ribbans (Aug 26)
- RE: More on Shatter Kayne Ian (Softlab) (Aug 27)
- Re: More on Shatter Daniel Newby (Aug 23)