Re: More on Shatter

From: Dragos Ruiu (dr@kyx.net)
Date: 08/23/02 

From: Dragos Ruiu <dr@kyx.net>
To: "Daniel Newby" <dnewby@nomadics.com>, vuln-dev@securityfocus.com
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.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.) 

-- 
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

Relevant Pages

  • Re: OS X.4.X update...
    ... back" some languages you have removed, unless they are smart enough not ... has very little in the way of multiple language support. ... applications which support Unicode - AppleWorks is not one of them). ... It doesn't even touch on the other things you can do with computers now ...
    (comp.sys.mac.system)
  • Re: Round One: "DLL Proxy" Attack Easily Hijacks SSL from Internet Explorer
    ... whole reason I play with computers in the first place. ... Practically all the network links, ... > significant way such that old applications will not run. ... Only for values of "people" not including programmers, ...
    (Bugtraq)
  • Re: Mac verses PC
    ... It is much easier to develop applications for Windows, ... lots of different kinds of development tools are free. ... That's why people bought computers, ...
    (rec.audio.pro)
  • Re: Sending Email
    ... Microsoft stops supporting older versions and sells what are ... really bug fixes as new applications... ... company hasn't completely changed out its older computers. ...
    (microsoft.public.access.formscoding)
  • Re: [PATCH] Input: Support for a less exclusive grab.
    ... There will always be an "arms race", new applications would ... I do believe there needs to be some concept of filtering events in such ... No, rfkill want to see keypresses, period. ...
    (Linux-Kernel)
Quantcast