Vulnerability Development mailing list archives

RE: More on Shatter


From: "Kayne Ian (Softlab)" <Ian.Kayne () softlab co uk>
Date: Tue, 27 Aug 2002 11:38:31 +0100

Latency for the WM_TIMER message is irrelevant. Depending on your o/s it
will only fire around once every 50ms anyway, and it's a low priority
compared to other messages. Therefore if your machine is working under heavy
load, and you code an app to fire WM_TIMER's at every 50ms, your WM_TIMERS
might only get fired once every 200ms. Or 1000ms. Or 10 minutes. It's
undefined. As a sidenote, Windows will drop WM_TIMER messages that fall
outside the boundary - ie: if your WM_TIMER is set to fire every 100ms, and
due to processor load it takes > 100ms to get round to processing the
current WM_TIMER, it will be discarded. In other words, you'll never receive
2 WM_TIMERS in succession, and they don't stack up in the queue.

If you're after high resolution timers, you need to use
QueryPerformanceFrequency() counters.

There are a couple of things MS can do to "assist". I'm typing as I think of
them. First of all, implement a source keying system. The code required for
this would be minimal. Add an extra member to the WNDCLASSEX struct. This
could tell win32api to generate a GUID for this application instance. Then,
unless this GUID is included as an "extra" LPARAM (say, GPARAM?)with all WM_
in the loop, and it matches the GUID in the WNDCLASSEX, the message is
discarded. It could be a default param & struct member of NULL, which would
keep compatability with existing apps. Because it's registered in the
WNDCLASS, Windows could just add it to the WM_PAINT et al as required.
Second, MS could really handle the DefWindowProc() better. This would also
not break existing apps, but adding some controls to filter the source would
be a major bonus - why the hell would another app legitimately inject WM_ to
the messageloop only to have them handled by DefWindowProc(). 

With regard to the updated Shatter doc, saying that "it's unfixable" is
crap. Saying that "People are gonna disagree with that one, I know" is very
true, because calling it unfixable is wrong. 

Oh also, to the comment "Important servers/workstations should NOT use
win32". What, precisely, should they use instead of win32api? MagicAPI,
perhaps?

Ian Kayne
<Opinons are my own>

-----Original Message-----
From: Dragos Ruiu [mailto:dr () kyx net]
Sent: 23 August 2002 16:33
To: Daniel Newby; vuln-dev () securityfocus com
Subject: Re: More on Shatter


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



******************************************************************** 
This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom 
they are addressed. 

If you are not the intended recipient or the person responsible for 
delivering to the intended recipient, be advised that you have received 
this email in error and that any use of the information contained within 
this email or attachments is strictly prohibited. 

Internet communications are not secure and Softlab does not accept 
any legal responsibility for the content of this message. Any opinions 
expressed in the email are those of the individual and not necessarily 
those of the Company. 

If you have received this email in error, or if you are concerned with 
the content of this email please notify the IT helpdesk by telephone 
on +44 (0)121 788 5480. 

********************************************************************


Current thread: