思うに、プロセスＢにWM_TIMERを送ることでプロセスＢ内の処理を起動できることを
いっているような気がします。プロセスＢ内の処理なのでアドレス空間的には、プロ
セスＢの中になると思います。
問題なのは、WM_TIMERを発行した側が受ける側よりも低い権限で動作している場合に
処理そのものはプロセスＢの権限（発行した側よりも高い権限）で動作できてしまう
ために本来ならシステム上制限がかかるような操作も可能になってしまうということ
だと思います。

> （１）AのアドレスをlParamに指定してBで実行させる。
> （２）BのアドレスをlParamに指定してBで実行させる。
私も(2)だと思います。

プロセスＡがプロセスＢ内の関数を呼ぶことができることでしょう。
(1)ができれば何でもできてしまいますよね。

この題名の
「Windows WM_TIMER メッセージ処理の問題
　により権限が昇格する」
　　　　~~~~~~~~~~~~~~
は、(1)のようなニュアンスですが。

皆さん、ご意見ありがとうございます。

私がここに行き着いたのは、MSのダウンロード センター
　 http://www.microsoft.com/downloads/search.aspx?langid=13&displaylang=ja
にこのバグのパッチがランクインしていたからです。

やはり（２）の場合ですかね。
私はWM_TIMERメッセージのパラメータに関数アドレスなんかは（面倒だから）
指定したことはないのですが、MFCやWinSockあたりが勝手に
TIMERメッセージ待ちとかしてないですよね？ちょっち心配に
なってきました。

>(1)のようなニュアンスですが。

プロセスBの関数の仕様と入り口のアドレスが既知の場合、プロセスA
がその関数を狙い撃ちできる、という意味だと思います。
狙い撃ちできなくても、でたらめなアドレスを送ってプロセスBを
クラッシュさせることはできるんじゃないですか。