Re: Which process posts this window message ?
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Thu, 10 Dec 2009 17:05:09 -0500
See below...
On Thu, 10 Dec 2009 13:53:22 -0800, "David Ching" <dc@xxxxxxxxxxxxxxxxxxxxxx> wrote:
"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message****
news:1lt1i5hlg4g43dut7fk69hgkmeapv41koe@xxxxxxxxxx
I can imagine some very complicated, fragile, and potentially very
dangerous mechanisms
for detecting this, but they would involve DLL injection which would then
"hook" (but not
in the legitimage SetWindowsHookEx) all SendMessage/PostMessage/etc. calls
and if one of
them was targeted to a function in a forbidden app, doing something to
return immediately
to the caller. The real risk here is if there were any change whatsoever
to the
mechanisms you were running roughshod over (say, a drive-by update), then
every program on
the system would cease working. Not A Place You Want To Be.
I wouldn't deploy it, but API hooking is a great way of debugging who the
heck posted the unwanted message. I've done this and saved the client many
hours of billable time in addition to a large portion of my hair! ;)
Yes, API hooking was what I was referring to. While a fine short-term solution, to
implement the solution as a permanent solution seems risky.
****
****
Windows apps should be architected so they can withstand windows messages
from anyone. If it is important to validate the sender, a private mechanism
must be used between the sender and the app. For example, if you don't want
another app to post WM_CLOSE to your window so that your app terminates,
don't terminate when WM_CLOSE (or any other Windows message you can't
defend) is received.
You can only carry this so far. While WM_CLOSE could be defended against, there are lots
of other messages I could use to implement a D-O-S, such as messages to child windows to
delete items from list boxes, etc. So from a security viewpoint, only API hooking can
solve the problem, but it is not a really good solution in the long term.
*****
****
For example, one of my apps only terminates when a second instance is
launched with a "/kill" command-line switch specified, the second instance
then knows how to kill the first instance.
And there's my technique of putting a GUID in the front of a WM_COPYDATA packet to ensure
that only valid packets are processed. The problem is that each of these is a very
focused solution. The only general solution is API hooking. And the problem with that is
that it seems very high-risk to impose it system-wide as a permanent state.
joe
****
Joseph M. Newcomer [MVP]
-- David
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- References:
- Which process posts this window message ?
- From: Peter
- Re: Which process posts this window message ?
- From: Joseph M . Newcomer
- Re: Which process posts this window message ?
- From: David Ching
- Which process posts this window message ?
- Prev by Date: Re: Transparent,resizable and movable child window
- Next by Date: Re: Unicode, CRichEditCtrl, SetWindowText and Paste
- Previous by thread: Re: Which process posts this window message ?
- Next by thread: Error LNK2005: _DllMain@12 already defined in msvcrtd.lib(dllmain.obj) mfcs90ud.lib
- Index(es):
Relevant Pages
|
